From bottlenecks to breakthroughs
What happens when you put senior engineers in a room and ask them to question everything they believe about scale?
On 7th March 2026, we hosted our first Tech Talk at Entain India — a session called Scale Stories: From bottlenecks to breakthroughs. What started as a structured presentation quickly turned into a room full of engineering leaders from Tier-1 product organizations debating the uncomfortable truths about building systems at scale.
This wasn’t a typical conference talk. It was a conversation about the gap between what we say about scale and what we actually experience in the trenches. Co-leading the session alongside a leader from a Tier 1 tech company, I was struck by how universal the problems were. Different industries, different stacks, similar challenges.
Setting the stage: What does scale even mean?
We opened with a simple question that turned out to be anything but simple: What is scale?
At Entain, we operate across 30+ brands, 40 licensed territories, and 42 currencies. We power global tournaments and integrate with 300+ partners. But for us, scale is not just traffic; it is regulatory complexity, jurisdictional nuance, and trust.
In high-output digital platforms, every transaction carries real-world impact. A single user action triggers probability calculations, limit validations, and secure wallet updates within milliseconds. Scaling across millions of users under varied regional regulations proves why “just add more servers” is never the solution. The real challenge is building systems that are resilient and consistent by design.
Five lies we tell ourselves
The heart of the session was an interactive myth-busting exercise. I put five commonly held beliefs on the table and asked the room to challenge them.
-
Myth 1: “Microservices automatically scale better”
We asked for a show of hands. Most of the room initially agreed. Then we unpacked the reality: network tax, operational overhead, distributed failure modes, and the rapid growth in complexity that comes with decomposing a system into dozens of independently deployable units. Microservices are a tool, not a strategy. The room’s consensus shifted, it’s not about micro or mono, it’s about understanding your domain boundaries before you draw service boundaries. -
Myth 2: “Kubernetes solves architecture”
This one sparked a lively debate. Kubernetes is brilliant at orchestration, but orchestration is not design. As one participant put it: “You can’t orchestrate your way out of bad design decisions.” Scaling a poorly architected system with K8s just means you’re scaling failure more efficiently. The tooling has gotten so good that it’s easy to mistake infrastructure capability for architectural soundness. -
Myth 3: “Horizontal scale is always cheaper”
This is the one that hit home for many in the room. Infrastructure economics are non-linear. Sometimes vertical optimization, better algorithms, smarter caching, reducing unnecessary computation, delivers more value than throwing more instances at the problem. The question we kept coming back to: what’s your cost per transaction, and is it going up or down? -
Myth 4: “AI will reduce engineering headcount”
This was the most nuanced discussion of the evening. The consensus wasn’t that AI reduces complexity, it increases ambition. When teams get better tools, they don’t do the same work with fewer people. They attempt harder problems. AI amplifies capability, scope expands, and the quality bar rises. The real question isn’t whether AI replaces engineers, but whether we’re using it as leverage or as novelty. -
Myth 5: “We’ll refactor when scale forces us”
Every senior engineer in the room had a war story for this one. Technical debt compounds. Refactoring under pressure is expensive, risky, and often incomplete. The best time to address architectural debt was yesterday. The second best time is now. Waiting for scale to force your hand means you’re already behind.
Architecture therapy
The second half of the session shifted from myths to reality with a forum we called “Architecture therapy.” Through anonymous submissions, we surfaced the hidden bottlenecks that transcend company boundaries:
- Release governance that slows delivery to a crawl.
- Observability gaps that leave teams flying blind in production.
- CI/CD pipelines that have become productivity drains.
- Infrastructure costs that creep silently upward.
For each bottleneck, we asked: Is this a tech problem or an org problem? The answers were often surprising. Many of the hardest bottlenecks weren’t technical at all—they were organizational, cultural, or structural. Scale doesn’t fail loudly at first; it degrades silently through slower systems, tired teams, and rising costs.
What this shift means and why it matters now
Stepping back from the specifics of the session, there’s a broader shift happening in engineering that made this conversation feel especially timely. The industry is moving past the era where scale was primarily a capacity problem. Today, the real challenge is navigating complexity, organisational, regulatory, architectural — while still shipping with speed and confidence.
At Entain India, this is something we actively solve every day. We’re not a satellite office executing someone else’s roadmap. We’re the engineering and delivery powerhouse — building global products out of Hyderabad and Pune that serve millions of users across 130+ jurisdictions. That means every decision we make carries weight across brands, markets, and regulatory frameworks simultaneously.
The way we approach problem-solving here has evolved significantly. We focus on simplifying complexity wherever possible. That sounds obvious, but the difference is real. Managing complexity means adding process, adding layers, adding governance. Reducing it means questioning whether the complexity needs to exist at all.
A few examples of how this plays out in practice at Entain India:
- When teams hit cross-market duplication, the same problem being solved independently by different squads, we don’t just coordinate better. We ask whether the problem should be solved once, as a platform capability, rather than N times as feature work.
- When release governance becomes a bottleneck, we don’t add more approvers. We invest in automated quality gates, better observability, and progressive rollout strategies that make the governance lighter because the safety nets are stronger.
- When infrastructure costs creep, we don’t just right-size instances. We go upstream — profiling workloads, questioning architectural assumptions, and sometimes discovering that the most expensive thing in the system is a design decision made two years ago that nobody revisited.
This is the friction reduction mindset. Not friction as in “things are slow” friction as in the invisible resistance that accumulates in systems and organisations over time. Merge conflicts that slow down teams. Handoffs that introduce delays. Tribal knowledge that creates single points of failure. These are the bottlenecks that don’t show up on any dashboard but quietly erode velocity and morale.
What I’ve seen work at Entain India and what resonated with the leaders in the room that evening is that meaningful progress comes from teams that are empowered to question the status quo. Not in a disruptive way, but through a disciplined, evidence-driven approach. We focus on identifying and addressing what matters most. Name the bottleneck. Propose a smaller, better path. Ship it. Learn.
The Tech Talk itself was an expression of this philosophy. We created a space for senior engineers to connect, share and learn from each other. That’s how friction gets removed: when people come together to make things better.
The breakthroughs
Meaningful progress comes from teams empowered to question the status quo through a disciplined, evidence-driven approach. Across the stories shared, a few themes for breakthroughs emerged:
- Question sacred patterns: Just because it worked at 100k users doesn’t mean it works at 1M.
- Measure before scaling: The instinct to add capacity is strong, but the bottleneck is often where you aren’t looking.
- Treat reliability as a product: It isn’t a tax on development; it’s a feature in itself.
- Build leaders, not dependencies: Systems scale when knowledge and decision-making are distributed.