It’s arguably the most important concept in AI engineering right now that most people outside the field have never heard of. Here’s the full picture — what it is, why it exists, what it’s built from, and why it might matter more than which AI model you’re using.

The One-Line Version

An AI model, on its own, can only do one thing: read text and generate more text. It cannot browse a website, run code, remember what happened yesterday, or check its own work. Ask a raw model to “fix the bug in this file and deploy it,” and it can describe what it would do — it cannot actually do it.

A harness is the software wrapped around that model that gives it the ability to actually act: running code, calling tools, remembering context, checking its own results, and staying within safe boundaries. The formula the field has settled on is simple:

Agent = Model + Harness

The model is the brain. The harness is everything else — the hands, the memory, the rulebook, and the workspace.

Where the Term Came From

The word “harness” in this context is recent — it only really entered common use in early 2026, and even now its exact origin is genuinely disputed. Several accounts trace it to a blog post by Mitchell Hashimoto, the co-founder of infrastructure company HashiCorp, describing the practice of engineering a permanent fix into an agent’s environment every time it makes a mistake. Other accounts credit a widely shared “Anatomy of an Agent Harness” post from LangChain, which derived the concept directly from the Agent = Model + Harness formula.

What isn’t disputed is what accelerated it: a widely read engineering report from OpenAI describing a large production codebase built largely by coding agents, followed by detailed technical writing from Anthropic, Thoughtworks, and Databricks. By mid-2026, the harness had gone from a niche engineering term to the subject of academic papers and its own comparison charts, with roughly a dozen competing harness products in active use.

The Loop at the Center of Everything

To understand why a harness needs so many separate pieces, it helps to see the basic cycle every agent runs on repeatedly. It’s usually called the ReAct loop, short for “reason and act,” and it goes like this:

1. Reason. The model looks at the task, whatever it already knows, and whatever happened in previous steps, and decides what to do next.
2. Act. The harness actually carries that decision out — running a piece of code, calling an API, searching the web, or writing to a file.
3. Observe. The harness captures whatever happened as a result and feeds it back to the model as new information.
4. Repeat. The model uses that new information to decide the next step, and the cycle continues until the task is actually finished.

Take a coding agent asked to fix a bug. The model proposes a code change. The harness runs that code in an isolated environment, captures whether the tests pass or fail, and reports back. If something failed, the model reasons about why and tries again. The model never touches the actual file system or the actual test runner directly — the harness stands between the model’s reasoning and the real world at every single step.

The Eight Pieces Every Serious Harness Is Built From

Different products implement this differently, but almost every production-grade harness is assembled from the same core building blocks.

System prompts. The standing instructions given to the model every single time it runs — who it is, what it’s meant to accomplish, and what rules it must never break. A surprising amount of unpredictable agent behavior traces back to a poorly written system prompt rather than a limitation of the model itself.

Tools and tool execution. Pre-built functions the model can call on — searching the web, querying a database, sending a message, running code. The model decides which tool it needs and when; the harness is what actually executes that tool and hands the result back. The field is increasingly moving away from giving a model dozens of narrow, single-purpose tools and toward simply giving it the ability to write and run its own code, letting it construct whatever workflow the task actually needs.

Sandboxes. An isolated, contained environment where an agent can run code or take actions without any risk of affecting a real system. This is what makes it survivable when an agent’s code is wrong — the damage stays inside a box that can be reset or discarded. It’s also what allows companies to run hundreds of agents simultaneously without one agent’s mistake touching another’s work.

Filesystem and durable storage. A place for the agent to read and write files — code, notes, partial progress — that survives between sessions. Without this, an agent that gets interrupted halfway through a long task has no way to pick up where it left off.

Memory and context management. A raw model has no memory beyond whatever fits in its current context window, and that window fills up fast on a long task. The harness decides what stays fully visible to the model and what gets compressed or summarized as the conversation grows — a process called context compaction — and it’s what allows an agent to resume a task days later with a working sense of what it already did.

Feedback loops and self-verification. A good harness doesn’t just let the model act and move on — it checks the work. Running the actual test suite, inspecting the actual output, or prompting the model to review its own result before calling something finished. This is the single biggest factor separating an agent that reliably completes long, complex tasks from one that quietly declares victory on broken work.

Guardrails and human-in-the-loop controls. Explicit rules that block unsafe or unapproved actions — for instance, requiring a human to approve anything irreversible, like deleting data, sending a message to a real customer, or spending money. In regulated industries, these approval checkpoints usually aren’t optional.

Observability and logging. The ability to see exactly what an agent did, why it made each decision, and where something went wrong. For an individual developer this is a debugging tool. For a company running agents in production, it’s frequently a compliance requirement — an audit trail showing precisely what happened and under whose authority.

Why the Harness Can Matter More Than the Model

This is the part that genuinely surprises people the first time they hear it: as AI models converge on similar raw capability, the harness increasingly decides how well an agent actually performs in the real world.

The same underlying model can score dramatically differently on the same benchmark depending entirely on the quality of the harness wrapped around it. In one documented case, pairing a model with a purpose-built harness for complex enterprise document tasks raised its accuracy from roughly 36% to over 52% — nearly halving the error rate, without touching the model itself. A strong harness around a merely decent model routinely beats a weak harness around a more powerful one.

That’s a genuinely counterintuitive fact in an industry that mostly talks about “which model is smartest.” For most real production work, the honest answer is: it depends at least as much on what you built around it.

How This Fits Into the Bigger Picture of AI Engineering

Harness engineering is really the third stage in a pattern that’s been repeating as AI models got more capable, with the work steadily moving outward from the model itself:

• Prompt engineering — the earliest stage, focused purely on wording a single input well to get a better single response.
• Context engineering — curating exactly what information the model sees and when, the discipline behind most retrieval-based AI applications.
• Harness engineering — designing the entire system around the model: the tools, the sandboxes, the loop, the guardrails.

Prompt and context engineering haven’t disappeared — they’ve simply become smaller pieces inside the larger discipline of harness engineering. A good system prompt is still important. It’s just no longer the whole job.

Where This Actually Goes Wrong

Most real failures in production AI agents trace back to the harness, not the underlying model. The recurring patterns worth knowing:

• Context rot. As a conversation or task grows longer, reasoning quality quietly degrades unless the harness has a real strategy for trimming or summarizing older context.
• Tool overload. Handing a model dozens of tools at once tends to slow it down and increase confusion rather than expanding what it can do.
• Brittle tool wiring. A small, seemingly harmless change to how a tool is described can cause the model to misuse it in ways that are genuinely difficult to diagnose afterward.
• Weak verification. Without real tests or checks built into the loop, an agent can declare a task finished when the actual work is incomplete or wrong.
• Missing guardrails. An agent taking an irreversible action — sending a real message, deleting real data, making a real purchase — without a human checkpoint in place. This is where the most damaging incidents tend to happen.

The Enterprise Problem This Creates: Agent Sprawl

Most companies aren’t building one AI agent. They’re building dozens, across different teams, for different workflows, often on different underlying models. Without a shared, consistent approach to harness design, that turns into what the industry has started calling agent sprawl: a scattered collection of agents that nobody can reliably govern, evaluate, or improve as a whole.

The practical fix companies are converging on is shared harness infrastructure — a common layer for building, deploying, governing, and monitoring agents, rather than every team quietly reinventing memory management and guardrails from scratch. It’s the same instinct that led companies to standardize on shared infrastructure for databases or authentication, applied to this new layer of the stack.

What Happens as Models Keep Improving

A reasonable question is whether harnesses become unnecessary once models get smart enough to plan, self-correct, and stay on task without so much external scaffolding. The honest answer is: probably not entirely, though the balance will keep shifting.

Execution environments, tool orchestration, guardrails, and observability solve problems that exist regardless of how intelligent the underlying model becomes — a smarter model still needs a safe place to run code, still needs its actions logged for compliance, and still benefits from an explicit check before it does anything irreversible. Two ideas already emerging point at where this is heading: lightweight, disposable harnesses built for a single task and thrown away afterward, and natural-language harnesses, where engineers describe an agent’s intended behavior in plain instructions rather than code, lowering the bar for who can actually build one.

Why This Matters If You’re Building With AI

If your team is evaluating AI coding tools, customer-facing AI agents, or any kind of automated workflow, “which model should we use” is genuinely the smaller question. The harness around that model — how it manages memory, what guardrails exist before an irreversible action, whether its work is actually verified rather than just claimed — is usually what determines whether the resulting system is a genuinely reliable tool or an impressive demo that falls apart the first time it meets a real, messy production system.

At Onclick Innovations, this is exactly the layer we spend the most engineering time on when building AI-powered features for clients: not just picking a capable model, but designing the sandboxing, verification, and guardrails around it properly, before it ever touches a client’s real data or real customers.

Frequently Asked Questions

What is an AI agent harness?
An AI agent harness is the software infrastructure built around a language model that lets it take real actions rather than just generate text — including running tools, executing code in a sandbox, managing memory, checking its own work, and enforcing safety guardrails. The common shorthand is: Agent = Model + Harness.

What’s the difference between an AI agent, an AI model, and a harness?
The model is the reasoning engine that decides what to do next. The harness is the execution layer that carries those decisions out safely and reliably. The agent is the full working system that combines both.

Why does the harness matter more than people think?
As AI models converge on similar raw capability, harness quality increasingly determines real-world performance. The same model can score very differently on identical tasks depending entirely on how well the harness around it manages memory, verifies results, and orchestrates tools.

What are the main components of an AI agent harness?
Most production harnesses include a system prompt, tools and tool execution, a sandbox environment, persistent file storage, memory and context management, feedback and self-verification loops, guardrails with human approval checkpoints, and observability and logging.

What is “agent sprawl” and why does it matter for businesses?
Agent sprawl happens when an organisation builds many separate AI agents across different teams without a shared, consistent approach to harness design, making them difficult to govern, audit, or improve as a group. Companies are increasingly adopting shared harness infrastructure to solve this rather than letting every team build its own from scratch.

Share

The post What Is an AI Agent Harness? The Concept Quietly Running the AI Agent Boom appeared first on Blog.

In 2026, JioHotstar reported a peak of roughly 72.5 million concurrent viewers during the ICC Men’s T20 World Cup final — a figure Reliance cited as a global record for a single live stream. To put that in perspective, the Super Bowl, the biggest live event in American media, peaks at somewhere around 10 to 12 million concurrent streams. JioHotstar routinely handles six to seven times that number, on a network where the same match is being watched on a 5G phone in Mumbai and a patchy 2G connection in rural Bihar at the same time.

How does a single platform pull this off without the whole thing collapsing? The answer is a genuinely fascinating piece of engineering. Here’s a breakdown of what actually makes it work.

First, A Note on the Numbers

Cricket streaming numbers in India get thrown around loosely, so it’s worth being precise. There are two very different metrics that often get confused:

• Concurrent viewers — how many people are watching at the exact same moment. This is the hard engineering number. JioHotstar’s verified peak here is around 72.5 million.
• Cumulative reach — how many unique people watched at any point across a match or a tournament. This is where you see figures in the hundreds of millions or billions (IPL 2025 reportedly drew over a billion viewers across TV and digital combined).

Both are real, but they measure completely different things. The concurrency number is the one that keeps engineers awake at night, because that’s the load the system has to survive in a single instant. Everything below is about how that instant is handled.

The Core Problem: Cricket Traffic Isn’t Smooth, It’s Explosive

Most streaming platforms deal with fairly predictable demand. People start a Netflix show whenever they feel like it, spread across the evening. Cricket does the opposite.

Hotstar’s own engineers have described traffic that can spike 20x within ten minutes of a match starting. Worse, the spikes happen mid-match too. When a star batter walks out to the crease, or a wicket falls in a tense final over, millions of people who stepped away suddenly rush back at once. Tens of millions of users can join within a single over.

This creates a specific, brutal engineering challenge called the thundering herd: a huge number of clients all requesting the same thing at the same instant, potentially overwhelming any server that isn’t ready for them. The entire architecture is designed around surviving these sudden surges, not just handling a high steady load.

Building Block 1: Adaptive Bitrate Streaming

The single most important idea in mass live streaming is that not everyone gets the same video. Through a technique called adaptive bitrate (ABR) streaming, the platform encodes every live stream into multiple quality versions simultaneously — 4K, 1080p, 720p, 480p, 360p, and stripped-down low-bandwidth versions for 2G connections.

The app on your phone constantly measures your available bandwidth and picks the right version, switching seamlessly if your connection changes — without ever interrupting playback. A viewer on stadium Wi-Fi might get 360p while a viewer on home fibre gets 4K, both watching the same match from the same infrastructure, just receiving different renditions.

This isn’t a nice-to-have. In a country with wildly varying network quality, ABR is the core mechanism that lets one platform serve everyone at once instead of buffering for half of them.

Building Block 2: A Multi-CDN Strategy

Here’s a physics problem: delivering video to 70 million people simultaneously from a central set of servers is simply impossible. The bandwidth doesn’t exist. The solution is the Content Delivery Network (CDN) — a globally distributed network of edge servers that cache content close to viewers.

JioHotstar doesn’t rely on just one. It runs a multi-CDN strategy, distributing traffic across several providers (Akamai has long been a core partner, alongside others) and using an in-house load optimizer that dynamically routes each viewer through the least-congested CDN in real time, based on live measurements of latency and packet loss. If one provider starts struggling, traffic shifts to another automatically.

The result of all this caching is dramatic: during live cricket, over 90% of content requests are served from CDN cache rather than origin servers. That single fact is the biggest scaling lever in the whole system. At a 90% cache hit rate, the origin infrastructure only has to handle roughly a tenth of the apparent load — still enormous, but survivable.

Cache hit rate is the primary scaling lever. At 90%, the platform serves ten times the load its origin servers actually see.

Building Block 3: The Custom Autoscaler

Behind the video, hundreds of microservices handle everything else: login, subscriptions, live scores, chat, reactions, recommendations, payments. These run on a massive Amazon EKS (Elastic Kubernetes Service) cluster — at peak, the setup has been described as running on the order of 16 TB of RAM, 8,000 CPU cores, and 32 Gbps of peak data transfer.

The clever part is how it scales. Standard Kubernetes autoscaling reacts to CPU and memory usage — but by the time CPU climbs, the surge has already arrived and viewers are already buffering. A newly provisioned server can take around 90 seconds to become healthy and start serving traffic, and in cricket, 90 seconds is two overs and several million viewers too late.

So JioHotstar’s engineers built a custom autoscaler that reacts to concurrency directly — the actual number of active streams — rather than to lagging server metrics. It can spin up new capacity within about 30 seconds of detecting a rising trend, giving it a crucial 60-to-90-second head start over standard tooling.

Building Block 4: Prewarming and Predicting the Surge

Even a fast autoscaler is reactive. The most sophisticated part of the strategy is being proactive. Rather than waiting for load to arrive, the team prewarms infrastructure ahead of big matches — provisioning servers and load balancers in advance, based on estimated peak concurrency drawn from years of historical match data.

Cricket is unusually predictable in this respect. Engineers know an India-Pakistan game will draw a bigger crowd than a mid-table league fixture, and they know viewership climbs toward the final overs. That historical pattern lets them pre-position capacity for the wave before it hits, treating reactive autoscaling as a backup rather than the front line.

The Clever Optimizations Most People Never Notice

Beyond the big architectural pieces, some of the most interesting work is in the small optimizations that shave load off the system:

• Separating cacheable from non-cacheable data. Not every request is equal. A live scorecard or match summary doesn’t change every second, so it can be cached and reused. Engineers separated these cacheable APIs onto a dedicated path with lighter security checks and faster routing, dramatically increasing how many users each server could handle.
• Slowing down refresh rates that don’t matter. Features like “watch more” suggestions or certain stats overlays don’t need real-time updates. By slightly reducing how often they refresh, the platform cut total network traffic without any viewer noticing a difference.
• Accepting a small, deliberate delay. JioHotstar streams run roughly 30 to 40 seconds behind the live TV broadcast. This isn’t a flaw — it’s a deliberate trade-off. That buffer is exactly what gives the system room to handle adaptive bitrate switching and absorb network hiccups without the stream stalling.
• Feature flags for safe rollouts. New features (interactive overlays, new quality options) are rolled out to a small percentage of viewers first. If something breaks under real load, it can be switched off instantly for everyone without touching the core stream.

The Jio Advantage Nobody Else Has

There’s one structural advantage worth calling out. Because JioHotstar sits inside Reliance, it has a relationship with Jio’s telecom network and its 450-million-plus subscribers that no independent streaming platform can replicate.

That telecom data can inform where CDN edge nodes are placed — pre-positioning capacity in regions where network data shows dense cricket viewership before a match even begins. Controlling both the last-mile network and the streaming platform is a genuine edge in a market this large and this network-diverse.

Why This Matters Beyond Cricket

It’s tempting to file this under “interesting cricket trivia,” but the engineering lessons are universal. The Netflix livestream of the Jake Paul vs. Mike Tyson fight in late 2024 buffered and stuttered for many viewers — a reminder that even one of the most sophisticated streaming companies in the world can struggle with live sport when it hasn’t been engineered specifically for these explosive, unpredictable spikes.

The principles JioHotstar relies on — cache aggressively and treat cache misses as the exception, scale on the metric that actually predicts load, prepare for the surge before it arrives, and make deliberate trade-offs like accepting a few seconds of latency for stability — apply to any system that has to survive sudden, massive concurrency. That includes ticketing platforms during a sale, payment systems on a festival day, and any product that goes from quiet to viral in minutes.

At Onclick Innovations, this is exactly the class of problem we love: architecting systems that stay fast and reliable not on an average day, but on the single worst-case moment when everyone shows up at once. The best infrastructure isn’t the kind that handles a steady load. It’s the kind you never notice, precisely because it was built for the spike.

Frequently Asked Questions

How many people watch JioHotstar at the same time during big matches?
JioHotstar reported a peak of roughly 72.5 million concurrent viewers during the ICC Men’s T20 World Cup final in 2026, cited by Reliance as a global record for a single live stream. Cumulative reach across a full match or tournament runs far higher, into the hundreds of millions, but that counts unique viewers over time rather than at a single moment.

What cloud infrastructure does JioHotstar use?
The platform runs primarily on Amazon Web Services, using Amazon EKS (managed Kubernetes) to orchestrate its microservices, alongside a multi-CDN delivery strategy with partners such as Akamai. It uses a mix of on-demand and spot instances to manage cost at scale.

Why doesn’t JioHotstar buffer during peak cricket traffic?
A combination of adaptive bitrate streaming (serving different quality levels to different viewers), aggressive CDN caching that handles over 90% of requests, a custom autoscaler that reacts to concurrency in about 30 seconds, and prewarming infrastructure ahead of matches based on historical data.

Why is the JioHotstar stream a bit behind the TV broadcast?
The stream runs roughly 30 to 40 seconds behind live TV. This is a deliberate engineering trade-off — the delay creates a buffer that allows adaptive bitrate switching and absorbs network fluctuations, keeping the stream stable for tens of millions of viewers at once.

What is the thundering herd problem in live streaming?
It’s when a very large number of viewers request the same content at the same instant — for example, millions rushing back to the stream when a wicket falls — potentially overwhelming servers. Streaming platforms design specifically around absorbing these sudden surges rather than just handling steady high load.

Sources: figures and technical details in this article are drawn from Reliance’s public statements, Business Standard, published Hotstar/JioHotstar engineering talks and case studies, and industry technical analyses (2019–2026). Some detailed architecture specifics reported by third parties are described by those sources as informed inference rather than officially confirmed by JioHotstar.

Share

The post How JioHotstar Streams Cricket to 70+ Million People at Once Without Buffering appeared first on Blog.

The technology choices behind Netflix, Uber, WhatsApp, Instagram, Spotify and Airbnb reveal something the framework debates on social media rarely admit: there is no universally “best” stack. There is only the right stack for a specific problem, at a specific scale, with a specific team. Here is what each of these companies actually runs on — and the lesson behind each choice.

Netflix: Java, Cassandra and a Custom-Built CDN

Netflix serves over 300 million subscribers across 190 countries and is responsible for a significant share of global downstream internet traffic. Its technology choices reflect the scale of that challenge.

The frontend runs on React, with GraphQL (via Netflix’s open-source DGS framework) handling data fetching for most modern client surfaces, after years of relying on a custom system called Falcor. The backend is built predominantly in Java with Spring Boot, powering thousands of independently deployable microservices. Python and Go handle specific domains including machine learning and observability tooling.

For data storage, Netflix relies on Apache Cassandra as its primary scale-out NoSQL store, EVCache (a memcached-based system) for high-speed caching, and MySQL for transactional data like billing. Real-time data movement runs through Kafka and Netflix’s own streaming platforms, Mantis and Keystone.

Perhaps the most striking architectural decision is Open Connect — Netflix’s proprietary content delivery network. Rather than relying entirely on third-party CDNs, Netflix places its own caching servers directly inside internet service provider networks around the world, pushing content as close to viewers as possible during off-peak hours.

The lesson: when you operate at a scale where standard infrastructure no longer fits your problem, building proprietary infrastructure becomes the rational choice — not over-engineering.

Uber: Polyglot Microservices Built for Real-Time Geography

Uber’s engineering challenge is fundamentally about real-time coordination across location, time and millions of simultaneous transactions. The company’s technology stack reflects a deliberate move away from a single dominant language toward a polyglot microservices architecture.

Uber’s backend spans Go, Java and Node.js, chosen for different services based on performance requirements and team expertise. The company famously built its own database system, internally known as Schemaless, on top of MySQL to handle the specific consistency and scale requirements of ride data. PostgreSQL and MySQL both appear throughout the broader system for different workloads. Kafka handles the real-time event streaming that powers live trip tracking, surge pricing calculations and driver-rider matching.

Uber migrated from an early monolithic architecture to microservices specifically because a single application could not be scaled, deployed and maintained fast enough to support the company’s growth. This migration was not undertaken on day one — it happened in response to genuine scaling pressure.

The lesson: architecture should follow the shape of your actual problem. Uber’s real-time, geographically distributed coordination problem demanded an architecture that could evolve service by service, rather than a single codebase trying to do everything.

WhatsApp: Erlang and the Power of the “Boring” Choice

WhatsApp’s technology story is one of the most instructive in the industry. At the time of its acquisition by Facebook in 2014, WhatsApp was famously serving hundreds of millions of users with an engineering team that numbered only in the dozens.

The reason this was possible comes down largely to one technology choice: Erlang. Erlang is a programming language originally built by Ericsson for telecommunications systems — designed from the ground up to handle massive numbers of concurrent, lightweight connections with extremely high reliability. It is not a trendy language. It was never going to top a “hottest frameworks of the year” list. But it was exactly suited to WhatsApp’s core problem: keeping millions of persistent connections open simultaneously, reliably, with minimal overhead.

The lesson: the most-discussed technology is rarely the most appropriate one. WhatsApp chose a niche, decades-old language because it was the correct tool for the specific problem — and that choice let a tiny team support an enormous user base.

Instagram: Scaling to a Billion Users on Python

Instagram is frequently cited as proof that the programming language you choose matters far less than how you architect around it. The platform’s backend is built primarily in Python using the Django framework — a combination often dismissed as too slow for applications at serious scale.

Instagram has scaled past a billion users on this foundation. The data layer relies on PostgreSQL for core relational data and Cassandra for specific high-volume, high-availability workloads. Caching is handled through Memcached and Redis, which absorb the read load that would otherwise hit the database directly for every request.

What made this scale possible was not a language switch but disciplined engineering around the language: aggressive caching strategies, careful database sharding, asynchronous processing for non-critical paths, and a willingness to optimise the specific bottlenecks that actually appeared under real load rather than guessing in advance.

The lesson: a programming language’s raw performance characteristics matter far less at scale than the architecture built around it. Bad architecture will make a fast language slow. Good architecture can make a famously “slow” language scale to a billion users.

Spotify: Microservices and the Squad Model

Spotify’s technology stack centres on Java and Python across a large number of independently owned microservices, with Google Cloud Platform and BigQuery handling much of its data infrastructure, and Kafka powering real-time event streaming for everything from play counts to recommendation signals.

What makes Spotify particularly interesting is not just the technology but the organisational model built around it. Spotify popularised the “squad” model — small, autonomous, cross-functional teams that each own a specific service or feature area end to end, with the freedom to choose their own tools and deployment cadence within broad guardrails.

This organisational structure and the underlying microservices architecture reinforce each other. Independent services map naturally onto independent teams, allowing Spotify to ship changes across a vast product surface without every team needing to coordinate on every release.

The lesson: technical architecture and organisational structure are deeply connected. The way you split your codebase into services often ends up mirroring — or should mirror — the way you split your teams. This is sometimes called Conway’s Law, and Spotify is one of its most-cited modern examples.

Airbnb: Starting on Rails, Evolving Under Scale

Airbnb’s technology story is a useful counterpoint to the others on this list because it illustrates evolution rather than a single static stack. The platform was originally built on Ruby on Rails — a framework chosen specifically for the speed at which it allowed a small founding team to build, iterate and ship a working product.

As Airbnb scaled into a global marketplace processing complex search, pricing and trust-and-safety logic, the company began migrating performance-critical and team-isolated portions of its system toward service-oriented architectures using languages including Java and Kotlin, while React became the standard for frontend development. MySQL and Redis remain core to the data layer.

Airbnb did not rewrite everything overnight, and it did not start with a microservices architecture from day one. The migration happened gradually, driven by specific scaling pain points rather than a wholesale rejection of the original technology choice.

The lesson: starting with a framework optimised for development speed is often the correct early-stage decision, even if it is not the architecture you will run at massive scale. Re-architecting in response to real growth is normal and expected — it is not a sign that the original choice was wrong.

What These Six Stacks Teach Every Founder and CTO

Looking across all six companies, four patterns emerge that matter far more than any individual technology choice.

There is no universally best stack. Java works for Netflix and Spotify. Python works for Instagram. Erlang works for WhatsApp. Ruby on Rails worked for early Airbnb. Each choice was correct for the problem, team and stage it was made for — not because of any inherent superiority of the language itself.

Boring, proven technology beats trendy technology at scale. None of these companies built their core infrastructure on whatever was generating the most hype on social media at the time. Cassandra, MySQL, Kafka and PostgreSQL are not exciting choices. They are reliable ones, with deep operational knowledge available across the industry.

Architecture matters more than the language itself. Instagram on Python and WhatsApp on Erlang both scaled to enormous user bases despite using technologies that are, by raw benchmark numbers, far from the fastest options available. The architecture built around the language — caching strategy, database design, service boundaries — determined the outcome far more than the language choice alone.

Start simple and re-architect when growth demands it. Airbnb did not start with a complex microservices architecture. WhatsApp did not start by trying to anticipate Facebook-scale traffic. Every one of these companies built something that worked for their actual stage, then evolved the architecture as real scaling pressure emerged — not in anticipation of hypothetical future scale.

How Onclick Innovations Approaches Technology Decisions

At Onclick Innovations, we do not have a default stack we push onto every client regardless of fit. We have built production applications in React, Vue and Angular for the frontend, and Node.js, Python, PHP and Java for the backend — choosing based on the specific project, team, timeline and long-term maintenance considerations involved.

The pattern across the six companies in this article holds true for every project we work on, regardless of size: the right technology choice is the one that fits the actual problem you are solving today, with room to evolve as your product and user base grow. Not the most fashionable choice. Not the one with the most active hype on social media this month. The right one for your specific situation.

If you are making technology decisions for a new product, or reconsidering the architecture behind an existing one, we are happy to talk through the tradeoffs honestly.

📩 Get in touch → www.onclickinnovations.com
📍 Based in Mohali, India · Serving clients globally across 10+ countries

Frequently Asked Questions

What programming language does Netflix use?

Netflix uses Java with Spring Boot as the primary language for its backend microservices, React for its frontend, and Python and Go for specific domains like machine learning and observability. Its data layer relies on Apache Cassandra, EVCache and MySQL, with Kafka handling real-time event streaming.

Why does WhatsApp use Erlang?

WhatsApp chose Erlang because it was specifically designed for telecommunications systems that need to handle massive numbers of concurrent, lightweight connections with high reliability and minimal overhead. This made it exceptionally well suited to WhatsApp’s core technical challenge of maintaining millions of simultaneous persistent connections, allowing a small engineering team to support an enormous global user base.

How did Instagram scale to a billion users on Python?

Instagram scaled on Python and Django through disciplined architecture rather than raw language performance: aggressive caching with Memcached and Redis, careful database sharding across PostgreSQL and Cassandra, and asynchronous processing for non-critical operations. This demonstrates that architectural decisions around a language matter more than the language’s raw benchmark speed.

Should a startup choose the same tech stack as a company like Netflix or Uber?

No. The technology choices made by Netflix, Uber and similar companies were shaped by their specific scale, team size and problem domain at the time those decisions were made — often after years of evolution from much simpler starting points. A startup should choose technology that fits its current stage, team expertise and actual requirements, with an architecture that can evolve as real growth demands it, rather than copying the infrastructure of a company operating at a vastly different scale.

Can Onclick Innovations help us choose the right technology stack for our product?

Yes. We help clients evaluate technology decisions based on their specific project requirements, team composition, timeline and growth plans rather than defaulting to a single preferred stack. Contact us at onclickinnovations.com to discuss your project.

Share

The post The Tech Stack Behind 6 Famous Apps: What Netflix, Uber, WhatsApp, Instagram, Spotify and Airbnb Are Actually Built With appeared first on Blog.