Flipkart handles peak traffic through a hybrid cloud strategy that combines a private cloud platform built on millions of CPU cores with burst capacity on Google Cloud Platform during sale events. During the Big Billion Days, traffic climbs five to ten times above normal levels, with up to 300 million visitors and transaction volumes surging six to ten times. Flipkart manages this by pre-scaling microservices independently, using Apache Kafka for real-time event streaming at 1.25 million messages per second, distributing static content through a CDN, pre-warming servers with predictive models, and isolating failures through circuit breakers. The infrastructure is engineered to absorb sudden, massive demand without compromising uptime or user experience.

Introduction: Engineering for India's Biggest Shopping Day

Every year, when Flipkart launches its Big Billion Days sale, millions of shoppers across India open the app simultaneously. In the first seconds after midnight, push notifications reach hundreds of millions of devices. Crores of taps hit the system within moments. Products sell out in minutes. Delivery slots fill up in hours.

What looks effortless to the end user is the result of years of infrastructure investment, architectural decisions made well in advance of the sale, and operational execution that begins months before a single product goes live.

The scale Flipkart operates at during Big Billion Days is genuinely exceptional. During BBD 2025, Flipkart expected over 300 million visitors, millions of simultaneous queries, and petabytes of data to process across its platform. Cities like Delhi, Mumbai, Bengaluru, and Kolkata recorded a doubling of order volumes compared to normal days. Smaller cities like Pune, Ambala, Chandigarh, and Panchkula saw a fourfold increase. Tier II locations across India saw significant upticks of their own.

This article breaks down exactly how Flipkart's infrastructure handles that load. Each section covers a specific layer of the architecture, with the actual technologies and engineering decisions behind it.

At Ascella Group, we work with engineering organisations building systems that need to perform under pressure. Flipkart's approach to peak traffic is one of the most instructive case studies in large-scale system design available today.

1. The Scale of the Challenge

To appreciate the engineering required, the numbers need to be stated clearly.

During normal operations, Flipkart manages substantial traffic. During Big Billion Days, traffic climbs to five to ten times those levels. Transaction volumes surge six to ten times. The platform must ingest over 130 billion messages per day during peak event periods, compared to around 60 terabytes of compressed data daily in regular operations. At the peak of real-time data processing, the system handles 1.25 million messages per second.

This is not a gradual ramp. The spike is sharp. At midnight when the sale opens, or at specific flash sale moments during the day, the load jumps almost instantly. Systems that cannot pre-scale or auto-scale fail under this kind of demand profile. Flipkart has engineered specifically for this pattern.

The challenge has three dimensions. The first is raw capacity: do you have enough compute to serve the requests? The second is coordination: can your databases, queues, and services keep up without blocking each other? The third is resilience: when individual components reach their limits, does the failure stay contained or does it cascade across the platform?

Flipkart's architecture addresses all three.

2. The Hybrid Cloud Foundation

Flipkart does not run purely on public cloud infrastructure and it does not run purely on private hardware. It runs on both, in combination, with each serving a specific purpose.

The foundation is Flipkart's own private cloud platform, referred to internally as the Flipkart Cloud Platform or FCP. This runs across private data centres in India and is built on millions of CPU cores. It provides the cost-effective baseline capacity that handles day-to-day traffic year-round. Running on private infrastructure at this scale is cheaper per unit of compute than relying on public cloud for baseline load.

The limitation of private infrastructure is that it cannot scale elastically in minutes. Flipkart cannot add thousands of servers to its private data centres overnight before a sale event. This is where Google Cloud Platform enters.

Flipkart uses GCP to burst workloads during peak periods. When demand exceeds what the private cloud can absorb, traffic and processing tasks overflow to GCP, which can provision capacity within minutes. This hybrid approach solves the core economics problem of peak infrastructure: you do not need to own hardware sized for your worst-case traffic when cloud burst capacity exists.

The practical outcome of this model is described in Flipkart's own engineering documentation. Compute requirements can fluctuate two to ten times during major sale events. The private cloud handles the baseline. GCP absorbs the overflow. If the private cloud experiences an issue, GCP ensures continued availability. The architecture gives Flipkart both cost efficiency and genuine resilience.

Flipkart's partnership with Google Cloud has also extended to migrating specific platforms. The Flipkart Data Analytics Platform and the Content Catalog Object Store have both been moved to Google Cloud infrastructure, enabling more scalable data processing and analytics during events.

3. Microservices Architecture: Scaling Each Function Independently

Flipkart does not scale its platform as one large unit. It scales specific functions independently based on where demand is highest at any given moment.

This is the core benefit of a microservices architecture. Each service handles a single business function. Product search, user authentication, inventory management, order placement, payment processing, recommendations, and notifications each run as separate services. They communicate through well-defined APIs. They deploy independently. They scale independently.

During Big Billion Days, the search service may receive ten times its normal load within seconds of the sale opening. The payment service sees its peak a few minutes later, as purchases are confirmed. The recommendations engine processes in the background. Each of these services scales to its own demand without requiring the entire platform to scale uniformly.

Flipkart's backend services are primarily written in Java, using Spring Boot as the framework for building microservices. Spring Boot reduces the time required to create production-ready services, which matters both for the ongoing engineering velocity and for the ability to deploy changes quickly during a live event.

The Kubernetes layer manages containerised deployments of these services across both the private cloud and GCP. Flipkart has used OpenEBS for persistent storage within Kubernetes, supporting stateful workloads including relational databases, NoSQL databases, caching layers, and machine learning pipelines. At any given time, there are several dozen different stateful workloads running in production across the platform.

Nginx handles web infrastructure, managing high volumes of concurrent connections and distributing them efficiently. It serves as the front-facing layer that routes incoming requests before they reach the application services.

4. Apache Kafka and Real-Time Event Streaming

One of the most important technical decisions in Flipkart's architecture is its use of Apache Kafka as the backbone for real-time data processing and event streaming.

In a platform handling millions of orders, every action generates an event. A product is viewed. A cart is updated. An order is placed. A payment is processed. An inventory count changes. A delivery status updates. In traditional architectures, these events are handled synchronously: service A calls service B, waits for a response, then calls service C. Under extreme load, this chain of synchronous calls creates bottlenecks. Slow services hold up fast ones. The system degrades.

Kafka removes this coupling. Events are published to Kafka topics and consumed asynchronously by the services that need them. The order service publishes an order-placed event. The inventory service, fulfilment service, and notification service each consume that event independently, in parallel, at their own pace. No service waits for another.

Flipkart's Kafka infrastructure handles the ingestion of over 130 billion messages per day during peak events, with 3,000 topics covering both general data and sensitive Personally Identifiable Information. At peak, the platform processes 1.25 million messages per second for real-time analysis.

As part of Flipkart's migration to Google Cloud, the data ingestion layer transitioned from on-premises Kafka to GCP's Pub/Sub service for certain workloads. This migration handled 60 terabytes of compressed data daily during regular operations and 500 terabytes per day during peak events. It covered 15,000 ETL jobs and over 80 petabytes of data in total.

Kafka also powers Flipkart's real-time inventory management. When a product sells out, that event propagates through the platform within milliseconds. The product listing is updated. The search index is updated. Recommendation logic excludes the unavailable item. This real-time coordination is not possible without a high-throughput streaming backbone.

5. Predictive Scaling and Pre-Warming Infrastructure

Auto-scaling is reactive. It adds capacity after traffic increases. For Flipkart's peak events, reactive scaling alone is not sufficient because the traffic spike can be near-instantaneous. If servers take two minutes to boot and the load doubles in thirty seconds, the gap matters.

Flipkart addresses this through predictive scaling using AI and machine learning models. Before a sale event, historical traffic patterns, marketing campaign data, expected user counts, and product category demand signals are fed into forecasting models. These models produce capacity estimates by service, by time window. Infrastructure is provisioned ahead of the spike, not in response to it.

This process is called pre-warming. Servers that will be needed at midnight are brought online an hour before. Caches are populated with high-demand product data, images, and pricing information. Database connection pools are sized for peak load. The goal is to ensure that when the first wave of traffic hits, the infrastructure is already in its scaled state.

Flipkart's AI-driven demand forecasting also extends to inventory management. Months before Big Billion Days, Flipkart works with sellers to stock warehouses with high-demand products. The forecasting models predict which products will sell fastest and in which geographies, enabling inventory to be pre-positioned close to expected demand centres. This directly reduces delivery times and the operational pressure during fulfilment.

The result of this preparation is visible in the BBD 2025 performance data. Flipkart Minutes delivered an iPhone in under three minutes during peak hours. Doorstep smartphone assessments were completed in approximately 30 minutes. These delivery metrics are only achievable when both the digital infrastructure and the physical logistics infrastructure are pre-scaled correctly.

6. Content Delivery Networks and Caching

Not every component of a web request needs to be generated dynamically. Product images, promotional banners, static page elements, and JavaScript bundles are the same for every user. Generating them from a server in Bengaluru for every user across India is unnecessary work.

Flipkart uses a Content Delivery Network to cache static assets at edge locations distributed across India. When a user in Lucknow opens the Flipkart app, images and page assets load from a CDN node nearby rather than from a central server. This reduces latency, reduces the load on origin servers, and improves the experience for users in Tier II and Tier III cities.

Caching at the application layer works in parallel with CDN caching. High-demand product data, pricing, and availability information is cached in memory so that the database is not queried for every single user viewing the same product at the same moment. During a flash sale when lakhs of users are viewing the same five products simultaneously, effective caching is the difference between a responsive page and a timeout.

Flipkart also runs a MySQL fleet of 700 clusters to support its data operations, with caching layers in front of the database tier preventing the clusters from being hit with the full volume of read requests during peak periods.

7. Load Balancing and Circuit Breakers

Traffic entering Flipkart's platform does not go to a single server. Load balancers distribute incoming requests across multiple servers, ensuring no single instance becomes a bottleneck. During Big Billion Days, load balancers are the gatekeepers that keep each service running within its capacity envelope.

Flipkart's load balancing layer performs health checks continuously. If a server stops responding correctly, the load balancer removes it from the rotation and redistributes its traffic to healthy instances. This happens automatically, without manual intervention.

Circuit breakers operate at the service-to-service communication level. In a microservices architecture, services call each other constantly. If one service becomes slow or unavailable, without protection, every service calling it will also slow down or fail. The failure cascades. Circuit breakers prevent this. When a downstream service crosses a failure threshold, the circuit breaker trips and the calling service either fails fast, returns a cached response, or uses a fallback. The failure is contained.

This combination of load balancing and circuit breakers is what allows Flipkart to maintain availability even when individual components are under extreme stress. The platform can absorb partial failures without presenting them to users.

8. Message Queues for Checkout and Order Processing

When a user clicks Buy Now during Big Billion Days, that action does not instantly write to a database. It enters a queue.

Message queues are used to smooth out the processing of orders during peak moments. The queue accepts incoming orders as fast as they arrive and feeds them to processing systems at the rate those systems can handle. This decouples the rate of incoming requests from the rate of database writes, preventing the database from being overwhelmed by simultaneous writes.

This architecture also improves the reliability of the checkout flow. If the payment processing service is briefly slower than normal, orders do not fail. They wait in the queue and are processed in sequence. The user experience remains intact. The back-end processing catches up within seconds.

The same pattern applies to inventory deductions, fulfilment triggers, and seller notifications. Each is handled asynchronously through a queue rather than synchronously in the critical path of the user's checkout flow.

9. Operational Readiness: What Happens Before the Sale Opens

The technical infrastructure is only part of the story. Flipkart's ability to handle peak traffic also depends on operational readiness in the weeks and months leading up to the event.

Flipkart enforces a code freeze before Big Billion Days. No new code is deployed in the period immediately before the sale. Only bug fixes and critical patches are permitted. This reduces the risk of a deployment causing unexpected behaviour during the event.

Load testing is conducted at scale before the sale. Teams simulate peak traffic conditions against production-grade infrastructure to identify bottlenecks before real users arrive. Services that fail under load are investigated and addressed before the sale opens.

Flipkart also adds temporary capacity to its physical operations. For BBD 2024, the company scaled its last-mile delivery operations with 5,000 additional temporary delivery staff to ensure timely deliveries during the sales period. Warehouse capacity is expanded through automation and increased headcount ahead of the event.

On the night of the sale launch, dashboards display traffic per second, inventory counters, Kafka consumer lag, CPU and memory usage, and error rates in real time. Engineering teams are on call, watching the metrics, ready to act if any signal turns red.

10. The Numbers Behind BBD 2025

Specific figures from the 2025 event illustrate how the architecture performs under real conditions.

The platform handled over 300 million expected visitors. Flipkart Minutes, the quick commerce arm, delivered iPhones in under three minutes at peak. One in five shoppers participated in the smartphone exchange programme during peak hours, with assessments completed in around 30 minutes. Metro cities recorded double their normal order volumes. Several Tier II cities recorded four times their normal volumes.

At the data layer, the platform ingested 130-plus billion messages per day during the event, processed 1.25 million messages per second in real time, and managed 500 terabytes of data daily across its pipelines. The MySQL fleet of 700 clusters handled relational data queries across all services.

These numbers are the output of the architecture described in this article. They are not accidental. They are the result of hybrid cloud strategy, microservices decomposition, Kafka-based streaming, predictive pre-scaling, CDN distribution, and operational discipline executed consistently.

Key Lessons from Flipkart's Approach

Flipkart's peak traffic architecture contains principles that apply to any engineering organisation building for variable, high-stakes load.

Plan for the worst case, not the average. Flipkart's infrastructure is designed for six to ten times normal load, not for the median day. Most organisations design for the average and scramble during spikes.

Decouple everything that can be decoupled. Kafka, message queues, and circuit breakers exist to prevent one slow component from stopping everything else. Tight coupling is the most common cause of cascading failure under load.

Prepare the infrastructure before the traffic arrives. Pre-warming, code freezes, and load tests are operational disciplines, not engineering shortcuts. They reduce the probability of a problem during the event to near zero compared to reactive approaches.

Use hybrid cloud when it makes economic sense. Private infrastructure is cheaper at baseline. Public cloud is more flexible for spikes. Flipkart uses both for what each does best. This is more efficient than either-or.

Observability is non-negotiable during peak events. Real-time dashboards, structured logging, and distributed tracing allow engineering teams to act in seconds rather than minutes when something changes. Without visibility, teams are reacting blind.

Frequently Asked Questions

How much does Flipkart's traffic increase during Big Billion Days? Traffic increases five to ten times above normal operating levels during Big Billion Days. Transaction volumes surge six to ten times. For BBD 2025, Flipkart expected over 300 million visitors and processed 130-plus billion messages per day across its data infrastructure.

What cloud infrastructure does Flipkart use? Flipkart operates a hybrid cloud model. The baseline infrastructure runs on its private cloud platform across Indian data centres, built on millions of CPU cores. During peak events, workloads burst to Google Cloud Platform to handle the surge. The company has also migrated its data analytics platform and content catalog to GCP.

What is Apache Kafka used for in Flipkart's architecture? Kafka serves as Flipkart's real-time event streaming backbone. It handles over 130 billion messages per day during peak events across 3,000 topics, and processes 1.25 million messages per second for real-time analysis. It enables asynchronous communication between microservices, powers real-time inventory updates, and drives personalised recommendations.

How does Flipkart prevent system failures during peak traffic? Flipkart uses circuit breakers to contain failures within individual services and prevent cascading outages. Load balancers distribute traffic across healthy instances with automatic failover. Message queues absorb order bursts without overwhelming databases. The hybrid cloud provides redundancy if the private cloud encounters capacity issues.

How does Flipkart scale its infrastructure before a sale event? Flipkart uses predictive AI and ML models to forecast traffic by service and time window, allowing infrastructure to be pre-warmed before the spike arrives. Caches are populated, connection pools are sized for peak load, and GCP capacity is provisioned in advance. A code freeze is enforced before the event to reduce deployment risk.

What is Flipkart's microservices approach? Flipkart runs its platform as hundreds of independent microservices, each responsible for a specific function such as search, checkout, inventory, or payments. These are built primarily in Java with Spring Boot, deployed in Kubernetes containers, and scaled independently during peak events based on the demand profile of each function.

Conclusion

Flipkart's ability to handle peak traffic without failure is not a matter of throwing more hardware at the problem. It is the result of architectural decisions made years in advance, operational disciplines applied months before each sale, and real-time engineering judgement exercised in the hours when hundreds of millions of users are active simultaneously.

The hybrid cloud strategy gives Flipkart cost efficiency and elastic capacity. Microservices give it the ability to scale individual functions independently. Kafka gives it a streaming backbone that can absorb over a billion messages per hour without bottlenecks. Predictive pre-scaling ensures infrastructure is ready before demand arrives. Circuit breakers and load balancers contain failures before they cascade.

The engineering principles behind all of this are not exclusive to Flipkart. Any organisation building systems that face variable, high-stakes load can apply the same thinking: decouple services, pre-scale for known peaks, build for failure containment, and maintain visibility over every layer of the system in real time.

At Ascella Group, we help engineering teams design infrastructure and architecture strategies that perform when it matters most. If your platform faces unpredictable traffic or significant peak events, these principles are the starting point for building something that holds.