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.

In that quarter of a second, an extraordinary sequence of events takes place across your device, multiple servers scattered around the planet, and several layers of internet infrastructure that most people never think about. This is the story of everything that happens in that invisible journey — from keystroke to pixel.

The Illusion of Instant

Modern browsing feels instant. That feeling is an illusion carefully engineered by decades of infrastructure investment, protocol optimisation and clever caching. Underneath that illusion is a genuinely complex pipeline involving your operating system, your router, your internet service provider, global naming systems, distant servers, and your browser’s rendering engine — all cooperating in milliseconds.

Understanding this pipeline is not just academic curiosity. It is one of the most useful mental models a developer, founder or technical decision-maker can have, because nearly every performance problem, security consideration and infrastructure cost in web development traces back to one of these steps.

Here is exactly what happens, step by step, from the moment you press Enter.

Step 1: Parsing What You Typed (0–1ms)

Before anything travels anywhere, your browser has to figure out what you actually typed. Modern address bars accept search terms, partial URLs and full addresses interchangeably, so the browser first determines whether your input is a valid URL or a search query destined for your default search engine.

If it is a URL, the browser parses it into its component parts: the protocol (http or https), the domain name, the path, and any query parameters. This happens locally, in well under a millisecond, before any network activity begins.

Step 2: The DNS Lookup (0–120ms)

Computers do not naturally know that “google.com” corresponds to a specific server. They need an IP address — a numerical identifier like 142.250.190.78. Translating a human-readable domain name into that IP address is the job of DNS, the Domain Name System, often described as the phone book of the internet.

The lookup process follows a specific order, checking increasingly slower caches until it finds an answer. First, the browser checks its own DNS cache — if you have visited this site recently, the answer may already be stored locally, and this step completes in under a millisecond. If not, the browser checks the operating system’s DNS cache, then potentially a local router’s cache.

If none of these have an answer, the request travels to a DNS resolver — typically operated by your internet service provider or a public resolver like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. This resolver may need to query a chain of authoritative servers: first a root server, then a top-level domain server (responsible for all “.com” domains, for instance), then finally the authoritative server for the specific domain, which returns the actual IP address.

A cold DNS lookup with no caching anywhere in the chain can take anywhere from 20 to 120 milliseconds — a significant portion of your total 300 millisecond budget, spent before a single byte of the actual website has been requested. This is precisely why DNS caching, and services like DNS prefetching, matter so much for perceived site speed.

Step 3: The TCP Handshake (20–100ms)

With an IP address in hand, your browser now needs to establish a reliable connection to that server. Most web traffic runs over TCP, the Transmission Control Protocol, which guarantees that data arrives complete, in order, and without corruption — a critical property for something as detail-sensitive as a web page.

Establishing a TCP connection requires what is known as a three-way handshake. Your browser sends a SYN (synchronize) packet to the server, essentially saying “I’d like to start a conversation.” The server responds with a SYN-ACK packet, acknowledging the request and proposing its own synchronization. Your browser then sends a final ACK packet, confirming the connection is established.

Each of these three packets has to physically travel across the network — through your router, your ISP, and potentially dozens of intermediate hops — before the next one can be sent. This round-trip time, often abbreviated as RTT, depends heavily on physical distance. A server on the other side of the world will always have a higher minimum TCP handshake time than one in a nearby data centre, no matter how well-optimised the software is, because the packets are limited by the speed of light through fibre optic cable.

Step 4: The TLS Negotiation (30–100ms)

If the connection uses HTTPS — which the overwhelming majority of the modern web does — an additional negotiation happens immediately after the TCP handshake completes. This is the TLS (Transport Layer Security) handshake, and it is responsible for the encryption that keeps your data private and verifies you are actually talking to the server you think you are.

During this negotiation, your browser and the server agree on which encryption protocols and cipher suites they will use, the server presents a digital certificate proving its identity (issued by a trusted certificate authority), and both sides generate the cryptographic keys that will encrypt all subsequent communication. Modern TLS 1.3, now the dominant standard, reduced this from two round trips down to effectively one, meaningfully cutting the time this step takes compared to older TLS versions.

By the end of this step, you have a secure, authenticated, encrypted channel open to the server — and you still have not received a single byte of the actual web page.

Step 5: The HTTP Request and Server Processing (10–200ms)

With the secure connection established, your browser finally sends the actual HTTP request — specifying which page it wants, along with headers describing your browser, accepted content types, cookies, and other metadata.

What happens next depends entirely on how the destination server is built. For a simple static site, the server might locate a pre-built HTML file and return it almost instantly. For a dynamic application, the server typically needs to run application code, which might query one or more databases, call external APIs, apply business logic, and assemble a response — all before sending anything back.

This is the step where backend architecture decisions have the most visible impact. A well-indexed database query might add 5 milliseconds. A poorly optimised one, missing the right index or fetching far more data than needed, can add hundreds of milliseconds all on its own. This is also where server-side caching, content delivery networks and edge computing earn their keep — by serving pre-computed or cached responses instead of repeating expensive work for every single request.

Step 6: Receiving the Response and Parsing HTML (5–20ms)

The server’s response arrives, typically starting with an HTML document. Your browser does not wait for the entire page to arrive before beginning work — it starts parsing the HTML as bytes stream in, building what is called the DOM, or Document Object Model: a structured tree representation of every element on the page.

As the parser encounters references to additional resources — CSS stylesheets, JavaScript files, images, fonts — it typically kicks off requests for those resources immediately, often in parallel, rather than waiting for the full document to finish downloading first. This parallelism is a major reason modern pages load faster than a naive step-by-step model would suggest.

Step 7: Building the Render Tree and Layout (5–30ms)

Once enough CSS has arrived, the browser combines the DOM with the CSS Object Model (the parsed representation of your stylesheets) to produce what is called the render tree — essentially the DOM, but annotated with exactly how each element should look.

The browser then performs what is called layout, or reflow: calculating the precise size and position of every single element on the page, accounting for the viewport size, box model rules, flexbox and grid layouts, and every CSS rule that affects geometry. This is genuinely one of the more computationally expensive steps in the entire pipeline, which is why excessive dynamic layout changes are a common cause of janky, sluggish-feeling web pages.

Step 8: Painting and Compositing (5–20ms)

With layout complete, the browser moves to painting — converting the render tree into actual pixels, filling in colours, text, images, borders, shadows and every other visual detail. Modern browsers optimise this further through compositing, where different layers of the page (an animated element, a fixed header, a video player) are rendered independently on the GPU and combined at the final moment, allowing smooth animations and scrolling without repainting the entire page from scratch.

This is the step where your screen finally shows something. On a fast connection with an optimised site, everything from the initial DNS lookup to this final paint can complete in well under 300 milliseconds — fast enough that the entire journey feels instantaneous to a human brain.

Why Every Millisecond in This Chain Matters

Google has published research showing that even small increases in page load time measurably increase bounce rates and decrease conversions. Amazon has cited internal data suggesting that every 100 milliseconds of additional latency measurably impacts revenue. These are not abstract engineering concerns — they are direct business outcomes tied to exactly the pipeline described above.

Every step in this journey represents an opportunity for optimisation, and every step represents a potential point of failure or slowdown if built carelessly. DNS prefetching, connection pooling, HTTP/2 and HTTP/3 multiplexing, TLS session resumption, database query optimisation, CDN edge caching, code splitting, lazy loading and critical rendering path optimisation are all, at their core, techniques aimed at shortening one specific step in this exact pipeline.

What This Means for Anyone Building Software

Understanding this journey changes how you think about performance. A slow page is never just “slow” in some vague sense — it is slow at a specific, identifiable step. Maybe DNS resolution is taking too long because there is no caching strategy. Maybe the TCP and TLS handshakes are slow because the server is geographically distant from most users, with no CDN in front of it. Maybe the server processing step is slow because of an unoptimised database query. Maybe the rendering step is slow because of render-blocking JavaScript or excessive layout recalculation.

Each of these has a specific, well-understood fix. But you can only apply the right fix once you understand which step in the pipeline is actually the bottleneck — which is exactly why this invisible 300-millisecond journey is worth understanding in detail, not just accepting as web browsing magic.

How Onclick Innovations Builds for Speed

At Onclick Innovations, performance is not an afterthought we address after launch — it is a consideration at every step of this pipeline, built in from the start. We implement CDN strategies to shorten physical distance to users, optimise database queries and indexing to keep server processing fast, apply modern HTTP protocols and TLS configurations to minimise handshake overhead, and build frontend code with the critical rendering path in mind.

The result is software that feels instant — because every millisecond in this 300-millisecond journey has been considered, measured and optimised.

If your website or application feels slower than it should, we are happy to help identify exactly which step in this pipeline is the bottleneck.

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

Frequently Asked Questions

What is a DNS lookup and why does it take time?

A DNS lookup translates a human-readable domain name like “example.com” into the numerical IP address computers use to locate a server. It takes time because, without caching, the request may need to travel through multiple servers — a resolver, a root server, a top-level domain server, and finally the domain’s authoritative server — each adding network round-trip time. Caching at the browser, operating system or router level can reduce a 100+ millisecond lookup to under a millisecond.

Why does HTTPS make websites slower than HTTP?

HTTPS requires an additional TLS handshake after the TCP connection is established, adding one or more network round trips to negotiate encryption before any page data is transferred. Modern TLS 1.3 has significantly reduced this overhead compared to older versions, and the security benefits far outweigh the small latency cost — which is typically tens of milliseconds, not a noticeable delay to users.

What is the biggest factor in how fast a website loads?

There is no single biggest factor — it depends on the specific site. Common major contributors include server response time (often tied to database query performance), geographic distance between the user and server (addressed by CDNs), unoptimised images and assets, render-blocking JavaScript and CSS, and inefficient rendering caused by excessive dynamic layout changes. Identifying the actual bottleneck for a specific site requires performance profiling rather than guessing.

What is the difference between the DOM and the render tree?

The DOM (Document Object Model) is the browser’s structural representation of the HTML document — every element and its relationship to other elements. The render tree combines the DOM with CSS styling information, representing only the elements that will actually be visually displayed, along with how each one should look. The render tree is what the browser uses to calculate layout and eventually paint pixels to the screen.

Can Onclick Innovations help improve our website’s load time?

Yes. We analyse performance across the entire request pipeline — from DNS and connection setup through server processing and frontend rendering — to identify the specific bottlenecks affecting your site and implement targeted fixes. Contact us at onclickinnovations.com to discuss your project.

Share

The post What Actually Happens When You Type a URL and Hit Enter appeared first on Blog.

But Amazon also supports dynamic content, CloudFront is a Content Delivery Network (CDN). CDNs are used to cache your web content at discrete locations around the world to reduce load times for users who are not near your web server. Amazon CloudFront is a global content delivery network (CDN) service that accelerates delivery of your websites, APIs, video content or other web assets. It integrates with other Amazon Web Services products to give developers and businesses an easy way to accelerate content to end users with no minimum usage commitments. Using the assistance of services like Amazon CloudFront implementation  you can get your entire website, including dynamic, static, streaming, and interactive content using a global network of edge locations. Requests for your content are automatically routed to the nearest edge location, so content is delivered with the best possible performance. Amazon CloudFront is optimized to work with other Amazon Web Services, like Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Load Balancing, and Amazon Route 53. Amazon CloudFront also works seamlessly with any non-AWS origin server, which stores the original, definitive versions of one’s files. Like other Amazon Web Services products, there are no long-term contracts or minimum monthly usage commitments for using Amazon CloudFront – you pay only for as much or as little content as you actually deliver through the content delivery service.

Share

The post Amazon CloudFront appeared first on Blog.