Flipkart Big Billion Days.

How Do You Open a Shop to Six Million People in the Same Minute, and Sell Five Thousand Phones Exactly Once Each?

It is 11:58 pm on 7 October 2026 in Bhagalpur. Rohan Mandal, a final-year engineering student, has had the same phone in his wishlist for three weeks. His Plus membership lets him into the sale at midnight, a day before everyone else. He has the app open on the phone's page and his UPI app logged in. The deal says ₹9,999 and "limited stock". He doesn't know how limited: 5,000 units, for everyone in India who has the same page open.

At 12:00:00 the button changes from "Notify me" to "Buy now". Rohan taps it at 12:00:01, and so do a few hundred thousand other people, from Bengaluru flats on fibre and from towns on one bar of 4G. In the next ten seconds something has to decide which 5,000 of them get the phone, tell everyone else the truth quickly, take money only from those 5,000, and never sell unit 5,001. Rohan also adds a washing machine for his parents before Diwali. The page says "Delivery by Tue, 13 Oct", and that has to stay true after millions of orders land on the same warehouses tonight.

This is the system we'll design today.

The Interview Begins#

You're interviewing at an e-commerce company. The interviewer shares two screenshots from the same phone: a product page at 12:00:00 with a red "Buy now" button and "Only a few left", and an order confirmation at 12:00:41 reading "Order placed · Delivery by Tue, 13 Oct".

Your Questions#

Functional Requirements#

Non-Functional Requirements#

The Opening Minutes#

Orders and Payments#

One Flash Deal#

Key Metrics Summary#

System Architecture#

%% title: A sale platform: a cached read plane, a small exact write plane, and one switch at midnight
flowchart TD
  subgraph L1["Layer 1 · People"]
    direction LR
    APP@{ icon: "sd:phone", label: "Flipkart app and site<br/>browse, deals, checkout" }
    OPS@{ icon: "sd:users", label: "Sale ops and sellers<br/>deals, prices, stock" }
  end
  subgraph L2["Layer 2 · Edge"]
    direction LR
    CDN@{ icon: "sd:cdn", label: "CDN<br/>pages, images, deal states" }
    GW@{ icon: "sd:gateway", label: "Gateway<br/>tiers, shedding, bot checks" }
  end
  subgraph L3["Layer 3 · Read plane"]
    direction LR
    SRCH@{ icon: "sd:search", label: "Search and browse<br/>index without prices" }
    PRICE@{ icon: "sd:cache", label: "Price and offer cache<br/>versioned price books" }
    PROM["Promise engine<br/>date per pincode, wave capacity"]:::core
  end
  subgraph L4["Layer 4 · Write plane"]
    direction LR
    ADM["Deal admission<br/>tokens per deal"]:::hot
    INV["Inventory<br/>holds with expiry"]:::hot
    CHK["Checkout and orders<br/>idempotent state machine"]:::core
    PAY["Payments<br/>routing, unknown outcomes"]:::core
  end
  subgraph L5["Layer 5 · State and partners"]
    direction LR
    KV@{ icon: "sd:database", label: "Stock and order stores<br/>strongly consistent" }
    BUS@{ icon: "sd:queue", label: "Message bus<br/>priority lanes" }
    BANK@{ icon: "sd:bank", label: "Gateways and banks<br/>UPI, cards, EMI" }
    FC@{ icon: "sd:warehouse", label: "Fulfilment centres<br/>waves and cut-offs" }
  end
  APP ==> CDN
  APP ==> GW
  OPS -.->|"staged before midnight"| PRICE
  GW --> SRCH
  GW --> PRICE
  GW --> PROM
  GW ==>|"Buy now"| ADM
  ADM ==> INV
  INV ==> CHK
  CHK ==> PAY
  PAY ==> BANK
  INV --> KV
  CHK --> KV
  CHK -->|"reserve a slot"| PROM
  CHK ==> BUS
  BUS ==> FC
  class APP client
  class OPS external
  class CDN,GW edge
  class SRCH service
  class PRICE cache
  class KV store
  class BUS queue
  class BANK external
  class FC store

KEY INSIGHTS:

• Two planes, two rules. The read plane may be seconds stale and is served from the CDN and memory; the write plane is exact and small, and nothing in it trusts a cached number
• The sale is a version, not an event. Prices, deals and pages for each phase are built and pushed before it starts; the start is one pointer flip
• Every hint has a commitment behind it. "In stock" on the page becomes a hold at checkout; "Delivery by 13 Oct" becomes a reserved slot in a warehouse wave; the price shown is the price charged

Data Flow: Rohan's Midnight Purchase#

%% title: Rohan buys the deal phone at 12:00:01
sequenceDiagram
  autonumber
  participant A as Rohan's app
  participant E as Edge and admission
  participant C as Checkout
  participant I as Inventory
  participant P as Payments
  participant B as Bank
  A->>E: Buy now, deal 4471, at 12:00:01
  E->>E: Within admission count, one per customer
  E-->>A: Token t93, valid 3 minutes
  A->>C: Checkout with t93, key k1
  C->>I: Hold 1 unit for 10 minutes, key k1
  I-->>C: Held
  C->>C: Order PENDING_PAYMENT, slot for 13 Oct held
  A->>P: Pay by UPI, key k1
  P->>B: Collect request
  B-->>P: Success
  P->>C: Paid, key k1
  C-->>A: Order confirmed

MEANWHILE, IN PARALLEL:

• Unpaid holds expire after 10 minutes and unused tokens after 3, admitting the next people in line; when both run out, the deal flips to "sold out" on the CDN
• The confirmed order goes over the message bus to the fulfilment centre, which picks it in the wave its slot was reserved in

Deep Dive 1: The Midnight Spike, a Peak You Can See Coming (Week 10 Concepts: Capacity Planning; Week 4: Thundering Herd)#

This builds on Week 10, Day 4 · Capacity Planning, Week 4, Day 3 · Thundering Herd and Week 4, Day 5 · Multi-Tier Caching.

What is published: in 2014 Flipkart "had deployed nearly 5000 servers and had prepared for 20 times the traffic growth", and traffic was still much higher. A Flipkart architect and Google Cloud wrote in 2023 that the sale brings "a transaction volume surge of six to eight times" business-as-usual, and that its data platform ingests about 60 TB of compressed messages a day normally and 500 TB a day at peak events. Aerospike reported in November 2024 that Flipkart's platform sustained 95 million transactions a second during The Big Billion Days, run on Kubernetes. A CNCF case study (2026) describes Flipkart's central chaos platform running 2,000+ experiments, finding 6+ critical misconfigurations ahead of TBBD 2024 and cutting the time to detect infrastructure failures by about 20% and to resolve them by about 25%.

• Forecast per surface, not per site. Pages multiply by the opening's concurrency; payments by far more (1,000× in Flipkart's words). Size each tier by its own multiplier, and give the banks and gateways the forecast too.
• Stateful tiers first. Databases and caches must rebalance data when they grow; grow them days ahead, then freeze.
• Rehearse failure, not just load. A load test proves capacity; a chaos test proves the fallbacks: kill a cache node or slow a bank at the forecast rate and check that shedding and breakers behave.
• Freeze changes. No deploys or config pushes in the sale window except fixes; every risky feature behind a flag.
• The app helps. It downloads the sale's assets hours ahead, counts down on the server's clock, and adds 0–3 s of random jitter to its first refresh after midnight, so 6 million phones don't ask in the same 100 ms.

%% title: The midnight switch: build ahead, push ahead, flip once
flowchart TD
  STAGE["Sale ops stage version v42<br/>prices, offers, deal states"]:::service
  BUILD["Build and validate v42<br/>guardrails, two approvals"]:::core
  PUSH@{ icon: "sd:cache", label: "Every cache node<br/>v41 live, v42 loaded" }
  EDGE@{ icon: "sd:cdn", label: "CDN<br/>v42 pages pushed, not live" }
  FLIP["12:00:00 · pointer v41 to v42<br/>one write, read everywhere"]:::hot
  APP@{ icon: "sd:phone", label: "Apps<br/>refresh with 0 to 3 s jitter" }
  STAGE ==> BUILD ==> PUSH
  BUILD ==> EDGE
  PUSH ==> FLIP
  EDGE ==> FLIP
  FLIP ==> APP
  class PUSH cache
  class EDGE edge
  class APP client

# sale/switch.py

"""
Switching a sale phase on by version (illustrative). Every price, offer and deal
state for the phase is written under a new version before it starts; the start
is one pointer write. Readers resolve the pointer, then read version-keyed
entries, so nothing expires or is rewritten at midnight.
"""

import time

ACTIVE = "sale:active_version"


def stage(kv, version: str, prices: dict, offers: dict, deals: dict) -> None:
    for sku, p in prices.items():
        kv.set(f"price:{version}:{sku}", p)            # new keys; the live version is untouched
    for sku, o in offers.items():
        kv.set(f"offer:{version}:{sku}", o)
    for deal_id, d in deals.items():
        kv.set(f"deal:{version}:{deal_id}", d)
    kv.set(f"ready:{version}", True)                   # set only after validation passes


def activate(kv, version: str, at_epoch: float) -> None:
    assert kv.get(f"ready:{version}"), "never flip to a version that isn't fully staged"
    while time.time() < at_epoch:
        time.sleep(0.01)
    kv.set(ACTIVE, version)                            # the whole switch is this one write

Deep Dive 2: Flash Deals and the Waiting Line (Week 3 Concepts: Backpressure and Flow Control; Week 1: Rate Limiting)#

This builds on Week 3, Day 3 · Backpressure and Flow Control, Week 1, Day 3 · Rate Limiting at Scale and Week 9, Day 5 · Security Architecture.

What is published: Flipkart hasn't published how it runs deal queues. On record: in 2014 Flipkart "ran out of the stock for many products within a few minutes (and in some cases, seconds) of the sale going live"; a month earlier, a flash sale on Flipkart sold 40,000 phones in 4.2 seconds to a pool of 250,000+ registered buyers (Xiaomi, reported by GSMArena, September 2014). In 2026 Flipkart reported that nearly one in two opening-hour visits came from Tier 3 towns and beyond, and about 60% of demand from outside the metros, which is why "fastest network wins" isn't a neutral rule.

• The line lives at the edge. Per deal: a counter of tokens issued and a set of holders, in memory with a replica. Issuing is one atomic increment-if-below-limit; refusing is a read.
• Tokens recycle. A token that expires unused, or whose payment fails, admits the next person in line, until the units are sold.
• "Sold out" is a state, published once on the CDN when tokens and holds are exhausted; later taps never reach the service.
• Bots are an economics problem. Per-customer, device and address limits make each extra phone cost a new verified account and address; signed, account-bound tokens can't be shared; risky sessions get a challenge before a token, never during payment.
• This is not the BookMyShow waiting room. BookMyShow (Bonus Problem 16) queues a whole on-sale because every seat is the scarce thing. Here the scarce thing is one product among millions, so the line wraps one button.

%% title: One tap on a deal: answered at the edge unless it can succeed
flowchart TD
  TAP["Buy now on deal 4471<br/>customer, device, address"]:::service
  BOT{"Limits and bot checks pass?"}
  WIN{"Inside the lottery window?"}
  LOT["Random order among<br/>taps in the first 2 s"]:::service
  TOK{"Tokens issued below<br/>units × 1.3?"}
  GIVE@{ icon: "sd:ticket", label: "Signed token<br/>3 minutes, one per customer" }
  WAIT["You're in line<br/>position shown"]:::service
  SOLD@{ icon: "sd:cdn", label: "Sold out<br/>published on the CDN" }
  TAP ==> BOT
  BOT -->|"no"| WAIT
  BOT ==>|"yes"| WIN
  WIN -->|"yes"| LOT ==> TOK
  WIN -->|"no"| TOK
  TOK ==>|"yes"| GIVE
  TOK -->|"no, tokens may return"| WAIT
  WAIT -.->|"all tokens used"| SOLD
  class GIVE ok
  class SOLD edge

# deals/admission.py

"""
Admission tokens for a limited deal (illustrative). Taps in the first seconds
are ordered randomly, then first come first served; tokens are capped a little
above the deal's units and recycled when they expire or their payment fails.
"""

import hmac, hashlib, random, time

WINDOW_S = 2.0            # erase network-latency advantage in the first seconds
OVERBOOK = 1.3            # tokens per unit, tuned from past drop-off
TOKEN_TTL_S = 180


def issue(kv, deal: dict, customer: str, now: float, secret: bytes):
    if kv.sismember(f"holders:{deal['id']}", customer):
        return {"status": "ALREADY_IN"}                      # one per customer
    if now < deal["starts_at"] + WINDOW_S:
        kv.zadd(f"window:{deal['id']}", {customer: random.random()})
        return {"status": "IN_LINE"}                         # drawn in random order when it closes
    return _try_admit(kv, deal, customer, now, secret)


def _try_admit(kv, deal, customer, now, secret):
    cap = int(deal["units"] * OVERBOOK) + kv.get_int(f"returned:{deal['id']}")
    if not kv.incr_if_below(f"issued:{deal['id']}", cap):    # one atomic step
        kv.rpush(f"line:{deal['id']}", customer)
        return {"status": "IN_LINE"}
    kv.sadd(f"holders:{deal['id']}", customer)
    expires = now + TOKEN_TTL_S
    msg = f"{deal['id']}|{customer}|{expires}".encode()
    sig = hmac.new(secret, msg, hashlib.sha256).hexdigest()  # bound to this account
    return {"status": "ADMITTED", "token": f"{msg.decode()}|{sig}", "expires": expires}

Deep Dive 3: Holding Stock Without Overselling (Week 5 Concepts: Consistency Models; Week 1: Hot Keys; Week 2: Idempotency)#

This builds on Week 5, Day 1 · Consistency Models, Week 1, Day 4 · Hot Keys and Skew and Week 2, Day 2 · Idempotency in Practice.

What is published: the 2014 email explained cancellations as many people buying the same product at once, so orders were accepted for items that had sold out seconds earlier, and the founders promised to "minimise any cancellations". Flipkart's engineers list inventory and pricing among the use cases on its Aerospike platform (Aerospike's write-up of their talk, 2025), and PingCAP describes Flipkart adopting TiDB, a distributed SQL database, after its MySQL setup hit limits on failover, replication and scale (2025). How Flipkart reserves stock, when, and for how long is not published; the rest is our design.

%% title: One unit of deal stock, from available to sold or back
stateDiagram-v2
  [*] --> AVAILABLE: received at a fulfilment centre
  AVAILABLE --> HELD: checkout starts, key k1
  HELD --> AVAILABLE: hold expired, no payment
  HELD --> PAYING: payment started
  PAYING --> SOLD: payment succeeded
  PAYING --> AVAILABLE: payment failed
  PAYING --> PAYING: outcome unknown, hold extended
  SOLD --> [*]
  class SOLD ok
  class PAYING queue

• Three numbers, one invariant. Per SKU per warehouse: available + held + sold = on hand. Holds, sales and expiries move units between them; a reconciler checks the sum every few minutes.
• Deal stock is its own pool, carved out before the sale under the deal's own counters, so a deal can't drain the regular listing.
• The hot key is bounded by the line. With admission in front, a deal sees ~6,500 holds in total, not 30,000 writes a second. If a non-deal product is still hot, split its stock into shards (per warehouse, then sub-shards), each decremented only while positive, so the shards can't add up to more than exist. Dream11 (Bonus Problem 25) does the same with mega-contest spots.
• Strong where it counts. Counter and hold record are one atomic write on a strongly consistent store; pages read replicas and caches. A page that says "In stock" a second too long costs a "sorry, just sold out" at checkout, not a cancelled order.
• Expiry is a sweep, not a timer per hold. Holds are indexed by expiry; a sweeper releases expired ones every second. A payment that succeeds after its hold was released takes another unit if one is free, or is refunded.

# inventory/hold.py

"""
Holding one unit at checkout (illustrative). The decrement and the hold record
are one atomic step on the stock store, keyed by the checkout id so a retry
finds the same hold. Holds expire unless a payment is in flight; a sweeper
returns expired units. available + held + sold always equals on hand.
"""

HOLD_S = 600              # 10 minutes to start paying
MAX_HOLD_S = 1800         # cap while a payment's outcome is unknown


class OutOfStock(Exception):
    pass


def hold(store, sku: str, fc: str, qty: int, key: str, now: float) -> dict:
    existing = store.get(f"hold:{key}")
    if existing:
        return existing                                      # a retry: same hold
    ok = store.transact([
        store.decrement_if_at_least(f"stock:{sku}:{fc}:available", qty),
        store.increment(f"stock:{sku}:{fc}:held", qty),
        store.put_if_absent(f"hold:{key}", {"sku": sku, "fc": fc, "qty": qty,
                                            "state": "HELD", "expires": now + HOLD_S}),
        store.index_add("holds_by_expiry", key, score=now + HOLD_S),
    ])
    if not ok:
        raise OutOfStock(sku)
    return store.get(f"hold:{key}")


def extend_for_payment(store, key: str, now: float, started: float) -> None:
    h = store.get(f"hold:{key}")
    new_exp = min(now + 300, started + MAX_HOLD_S)           # money in flight: wait, within a cap
    store.compare_and_set(f"hold:{key}", expect_state=h["state"], state="PAYING", expires=new_exp)
    store.index_add("holds_by_expiry", key, score=new_exp)


def sweep(store, now: float) -> None:
    for key in store.index_range("holds_by_expiry", max_score=now):
        h = store.get(f"hold:{key}")
        if h and h["state"] in ("HELD", "PAYING"):
            store.transact([
                store.compare_and_set(f"hold:{key}", expect_state=h["state"], state="RELEASED"),
                store.increment(f"stock:{h['sku']}:{h['fc']}:available", h["qty"]),
                store.increment(f"stock:{h['sku']}:{h['fc']}:held", -h["qty"]),
            ])
        store.index_remove("holds_by_expiry", key)

Deep Dive 4: Checkout and the Payment Surge (Week 2 Concepts: Idempotency, Circuit Breakers; Week 3: Transactional Outbox)#

This builds on Week 2, Day 2 · Idempotency in Practice, Week 2, Day 3 · Circuit Breakers, Week 2, Day 1 · Timeout Hell and Week 3, Day 2 · Transactional Outbox.

What is published: Gaurav Arora, Flipkart's vice-president of payments and SuperCoins, told Business Standard in September 2026 that Flipkart handles nearly 1,000 times more payment requests during peak festive periods than under normal business conditions, and that biometric-authenticated transactions recorded a 12–15% higher success rate than OTP-based ones in the payment flows discussed (as reported by DQIndia, which adds that a surge of that size can't be met by expanding Flipkart's own databases alone, since payments also run through banks, gateways, authentication services and telecom networks). Flipkart has open-sourced Phantom, a proxy for calling distributed services "inspired by Twitter Finagle clients" and built on Netflix Hystrix, used for "several hundred million API calls"; Varadhi, its REST message bus, in production for about ten years "sending billions of messages daily"; and a Kafka client with priority levels, where each level gets reserved consuming capacity (2018).

%% title: A double tap and an unknown outcome, resolved without a double charge
sequenceDiagram
  autonumber
  participant A as Rohan's app
  participant C as Checkout
  participant P as Payments
  participant G as Gateway
  participant R as Reconciler
  participant I as Inventory
  A->>C: Pay, key k1
  C->>P: Charge order o77, key k1
  P->>G: UPI collect for o77
  G-->>P: No answer in 30 s
  P->>C: o77 PAYMENT_UNKNOWN
  C->>I: Extend hold k1 while money is in flight
  A->>C: Pay again, key k1
  C-->>A: Payment in progress, no new charge
  R->>G: Status of o77?
  G-->>R: Success
  R->>C: o77 paid
  C->>C: CONFIRMED and outbox row, one transaction
  C->>I: Hold k1 becomes a sale

• The order is a state machine. PENDING_PAYMENT → PAYMENT_UNKNOWN or PAYMENT_FAILED or CONFIRMED → PACKED → SHIPPED → DELIVERED; each transition is a compare-and-set on the order's version, so two workers can't both confirm it.
• A timeout is unknown, not failed. It's never retried as a new charge; it's resolved by status polling, then by the gateway's settlement file the next day.
• Steer to the method that works. Order payment options by live success rate. A method with a 12–15% higher success rate, as Flipkart's Gaurav Arora reported for biometric authentication, is capacity: every failure is a retry that comes back.
• Bulkheads per partner. Each bank and gateway gets its own pool and concurrency limit, the Hystrix pattern Phantom was built on; a slow bank fails fast in its own pool and can't starve the others.
• Priority on the bus. Order confirmations, payment results and stock releases ride a high-priority lane; analytics and emails a low one, which waits when consumers fall behind.

# checkout/pay.py

"""
Paying for an order (illustrative). A second tap is a lookup by key; an
unanswered call is UNKNOWN, never retried as a new charge; a confirmed order
and its outbox event commit in one transaction.
"""

GATEWAY_TIMEOUT_S = 30


def pay(db, payments, inventory, order_id: str, key: str, method: str) -> str:
    attempt = db.get_payment_attempt(key)
    if attempt:
        return attempt.state                                 # second tap: show the first attempt
    db.insert_payment_attempt(key, order_id, method, state="STARTED")
    inventory.extend_for_payment(key)
    try:
        result = payments.charge(order_id, key=key, method=method, timeout_s=GATEWAY_TIMEOUT_S)
    except Timeout:
        db.set_attempt_state(key, "UNKNOWN")
        db.transition(order_id, "PENDING_PAYMENT", "PAYMENT_UNKNOWN")
        return "UNKNOWN"                                     # the reconciler takes it from here
    return settle(db, inventory, order_id, key, result.status)


def settle(db, inventory, order_id: str, key: str, status: str) -> str:
    with db.tx():
        if status == "SUCCESS":
            db.transition_any(order_id, ["PENDING_PAYMENT", "PAYMENT_UNKNOWN"], "CONFIRMED")
            db.outbox_add("orders.confirmed", {"order": order_id}, priority=0)   # same transaction
        else:
            db.transition_any(order_id, ["PENDING_PAYMENT", "PAYMENT_UNKNOWN"], "PAYMENT_FAILED")
        db.set_attempt_state(key, status)
    if status == "SUCCESS":
        inventory.mark_sold(key)
    else:
        inventory.release(key)
    return status


class Timeout(Exception):
    pass

Deep Dive 5: Prices, Catalog and Search Under Load (Week 4 Concepts: Cache Invalidation, Multi-Tier Caching; Week 7: Search)#

This builds on Week 4, Day 2 · Cache Invalidation, Week 4, Day 5 · Multi-Tier Caching and Week 7, Day 1 · Search Fundamentals.

What is published: the 2014 email: some prices changed to non-discounted rates for a few hours, and "we realise that this breaks the trust our customers have put in us". Flipkart's engineers list search, recommendations, ads, pricing and inventory among the use cases on its Aerospike platform, which Aerospike's write-up of their talk says serves "consistent sub-millisecond reads, even during Big Billion Days peaks" (2025). Its catalogue is 150 million products across 80+ categories (Flipkart, 2024; Google Cloud, 2023). How Flipkart versions prices or builds its search index for the sale isn't published.

%% title: Where a price comes from, on every page
flowchart TD
  PTR["Active version pointer<br/>v42 since 12:00:00"]:::hot
  BOOK@{ icon: "sd:cache", label: "Price book v42<br/>price, offers, deal state" }
  IDX@{ icon: "sd:index", label: "Search index<br/>titles, attributes, ratings" }
  SERP["Search results<br/>index hits plus prices joined"]:::service
  PDP["Product page<br/>price, offers, stock badge"]:::service
  CHK["Checkout<br/>re-price from v42, charge shown or lower"]:::core
  MISS["Price unknown<br/>no Buy button, retry"]:::bad
  PTR ==> BOOK
  IDX ==> SERP
  BOOK ==> SERP
  BOOK ==> PDP
  BOOK ==> CHK
  BOOK -.->|"miss or offers down"| MISS
  class BOOK cache
  class IDX store

• Search splits slow and fast fields. Matching and ranking use the index, refreshed in minutes; price, offer, stock and delivery date come from caches for the top results only.
• Cache the head. A few thousand queries ("smart tv", "washing machine") carry much of the sale's search traffic; their first page of result ids is cached for a minute.
• Degrade relevance, not results. Under load, drop personalised re-ranking first and cap result depth.
• Three tiers of cache. App, edge and in-memory stores in each data centre, all keyed by version: a version change makes every key new at every tier, without a purge.
• Offers are part of the version, so the discount on the page and at payment come from the same book and can't disagree.

# pricing/quote.py

"""
Quoting a price for a page or for checkout (illustrative). Every read goes
through the active version; a missing entry or an unreachable offer service
fails closed (no Buy button), never falls back to list price. Checkout
re-prices and charges the cart's price or lower.
"""

from decimal import Decimal


class PriceUnavailable(Exception):
    pass


def quote(cache, sku: str, card_bin: str | None = None) -> dict:
    v = cache.active_version()
    entry = cache.get(f"price:{v}:{sku}")
    if entry is None:
        raise PriceUnavailable(sku)                      # fail closed
    price = Decimal(entry["price"])
    offer = None
    if card_bin:
        offers = cache.get(f"offer:{v}:{sku}")
        if offers is None:
            raise PriceUnavailable(sku)                  # don't guess the offer either
        offer = best_offer(offers, card_bin, price)      # eligibility by card range, capped
    final = price - (offer["discount"] if offer else 0)
    return {"version": v, "price": price, "offer": offer, "final": final}


def checkout_price(cache, cart_line: dict, card_bin: str | None) -> Decimal:
    now = quote(cache, cart_line["sku"], card_bin)
    return min(now["final"], Decimal(cart_line["shown_final"]))   # never more than shown

Deep Dive 6: Delivery Promises That Survive the Surge (Week 10 Concepts: Capacity Planning; Week 3: Backpressure)#

This builds on Week 10, Day 4 · Capacity Planning, Week 3, Day 3 · Backpressure and Flow Control and Week 10, Day 1 · SLIs, SLOs and SLAs.

What is published: Flipkart's engineers wrote in 2026 that a Promise Engine "calculates the precise delivery date shown to a customer during checkout" from "available processing capacity across network and truck connection schedules". Fulfilment centres work in waves, each with a cut-off and a capacity (their example: a 12:30 cut-off with 20,000 units, and pick-to-dispatch times of 30 to 180 minutes), with operational constraints limiting a centre to 6–8 cut-offs a day. When a wave is full, orders "spill" to the next, and spilled orders "miss the truck and likely wait 24 hours for the next one". The engine typically allocates capacity first-in-first-out; Flipkart built a way to reserve capacity for orders with impending truck connections and, during sales such as BBD, when "demand massively exceeds capacity", for high-priority cohorts. Its Central Planning Platform forecasts demand down to pincode level (Flipkart Tech, 2026). Ahead of the 2026 sale, Flipkart said automation in Ekart's warehouses raised peak processing capacity by over 30% and that it added over 900 new delivery hubs (Flipkart, October 2026).

%% title: An order takes a slot in a wave, or the date moves
flowchart TD
  ORD["Order line<br/>washing machine to 812001"]:::service
  FCS@{ icon: "sd:warehouse", label: "Fulfilment centre<br/>holds the unit" }
  WAVE{"12:30 wave has capacity<br/>for this truck?"}
  RES["Reserve 1 unit of capacity<br/>urgent-truck share first"]:::hot
  TRUCK@{ icon: "sd:truck", label: "13:30 truck<br/>towards Bhagalpur" }
  SPILL["Next wave<br/>misses the truck, plus 1 day"]:::bad
  TABLE@{ icon: "sd:cache", label: "Promise table<br/>FC × pincode, recomputed" }
  ORD ==> FCS ==> WAVE
  WAVE ==>|"yes"| RES ==> TRUCK
  WAVE -->|"no"| SPILL
  RES -.->|"capacity left"| TABLE
  SPILL -.->|"new date for new viewers"| TABLE
  class FCS store
  class TRUCK external
  class TABLE cache

• Two promises, like two stocks. The page shows a cached date per (fulfilment centre, pincode), recomputed as capacity burns down; checkout reserves the slot. The order's date is the slot's date, not the page's.
• Promise = processing + transit. Transit is mostly fixed by truck schedules; processing is the variable, at each touch point (fulfilment centre, mother hub, delivery hub).
• Hold the slot with the stock. Both are made at checkout and released together if payment fails.
• Choose the warehouse by promise: the centre whose next feasible slot gives the earliest date, not the nearest one with a full wave.
• Under a surge, protect the cohort, show the truth to the rest. Reserve capacity for chosen cohorts and let other dates move out honestly: a later date before the order beats a broken one after it.

# promise/allocate.py

"""
Reserving capacity for an order (illustrative). Each fulfilment-centre wave has
a capacity and a cut-off; part of it is reserved for orders whose truck leaves
soon after the cut-off. If no feasible wave catches the truck, the promise
moves a day. The order keeps the date of the slot it reserved.
"""

from dataclasses import dataclass


@dataclass
class Wave:
    cutoff: int               # minutes after midnight
    capacity: int
    urgent_share: float       # part kept for orders whose truck leaves soon after the cut-off
    used_urgent: int = 0
    used_general: int = 0


def take(w: Wave, urgent: bool) -> bool:
    urgent_cap = int(w.capacity * w.urgent_share)
    if urgent and w.used_urgent < urgent_cap:
        w.used_urgent += 1
        return True
    if w.used_general < w.capacity - urgent_cap:      # urgent orders may also use the general share
        w.used_general += 1
        return True
    return False


def reserve(waves: list, now: int, p2d: int, truck_departs: int, transit_days: int, today: int) -> dict:
    for w in sorted(waves, key=lambda w: w.cutoff):
        if now + p2d > w.cutoff:
            continue                                  # can't be picked and packed by this cut-off
        catches_truck = w.cutoff <= truck_departs
        urgent = catches_truck and truck_departs - w.cutoff <= 120
        if not take(w, urgent):
            continue                                  # full: spill to the next wave
        ship_day = today if catches_truck else today + 1
        return {"wave": w.cutoff, "deliver_by_day": ship_day + transit_days}
    return {"wave": "tomorrow", "deliver_by_day": today + 1 + transit_days}

Rohan's Night, From the Platform's Side#

Edge Cases#

Monitoring Dashboard#

SLOs for the Sale#

The interviewer leans back. "One more."

Summary: Concepts Applied from 10-Week Course#

Why Flipkart Matters#

Self-Assessment Checklist#

After studying this case study, you should be able to:

The opening and the deals:

Stock, checkout and payments:

Prices, search and promises:

Sources#

Flipkart:

• Read

  Flipkart — India Logs on for The Big Billion Days: Flipkart Records 6.3 Million Concurrent Users as the Festive Season Opens (6.3 million concurrent users in a minute; Early Access at midnight on 8 October; 287 million+ sessions; 6× a regular hour; Tier 3 and non-metro shares), 9 October 2026: https://stories.flipkart.com/announcement/india-logs-on-for-the-big-billion-days-flipkart-records-63-million-concurrent-users-as-the-festive-season-opens

• Book

  Flipkart — Flipkart's Big Billion Days Returns for Its 13th Edition on October 9 (500 million registered customers; 150 million products; warehousing, processing capacity and delivery hubs added), 6 October 2026: https://stories.flipkart.com/announcement/flipkarts-big-billion-days-returns-for-its-13th-edition

• Read

  Flipkart — With 33+ Crore User Visits, Flipkart's Big Billion Days 2024 Kicks Off India's Festive Season (150 million products across 80+ categories; 19,000+ pincodes), 28 September 2024: https://stories.flipkart.com/announcement/with-33-crore-user-visits-flipkart-s-big-billion-days-2024-kicks-off-india-s-festive-season

• Read

  Flipkart — Millions served, lakhs empowered: Flipkart's festive supply chain at the heart of Bharat (BBD 2025: 7.3 million+ shipments in a day; 5,000+ a minute on peak days), December 2025: https://stories.flipkart.com/announcement/millions-served-lakhs-empowered-flipkart-s-festive-supply-chain-at-the-heart-of-bharat

• Blog

  Anjani Kumar — The Race Against the Clock: Optimizing Supply Chain Capacity for Faster Deliveries, Part 1 (the Promise Engine; waves, cut-offs and spillage; 6–8 cut-offs a day; capacity reserved for urgent trucks and for cohorts during BBD; 4 million+ daily shipments), Flipkart Tech Blog, 15 April 2026: https://blog.flipkart.tech/the-race-against-the-clock-optimizing-supply-chain-capacity-for-faster-deliveries-part-1-01b867c400de

• Blog

  Piyush Vyas — The Pulse of India's Supply Chain: How Flipkart Plans for 500 Million Customers, Part 1 (fulfilment centres, mother hubs, delivery hubs; the Central Planning Platform; pincode-level forecasts; 50% more 1-day deliveries), Flipkart Tech Blog, 5 May 2026: https://blog.flipkart.tech/the-pulse-of-indias-supply-chain-how-flipkart-plans-for-500-million-customers-part-1-50d241ca494f

• Read

  Flipkart — Varadhi, a message bus with a REST interface (about ten years in production, billions of messages daily), GitHub: https://github.com/flipkart-incubator/varadhi

• Read

  Flipkart — Priority Kafka Client (priority levels with reserved consuming capacity; first release October 2018), GitHub: https://github.com/flipkart-incubator/priority-kafka-client

• Book

  Flipkart — Phantom (service proxies inspired by Finagle, built on Netflix Hystrix; several hundred million API calls), GitHub: https://github.com/flipkart-incubator/phantom

Partners and case studies:

• Blog

  Sudhir Reddy (Flipkart) and Savitha Sethuram (Google) — Reshaping Flipkart's technological landscape with a mammoth cloud migration (6–8× BAU transaction volume; 7× in 2023; 60 TB vs 500 TB of messages a day; 1.25 million messages a second; scale tests to 5× BAU), Google Cloud Blog, 31 October 2023: https://cloud.google.com/blog/products/data-analytics/flipkarts-dx-journey-to-futureproof-its-platform

• Blog

  Aditya Tiwari (Flipkart) and Savitha Sethuram (Google) — The Bigtable Advantage: How Flipkart's fStream platform gets the most out of every byte (6–8× BAU transaction volume; the platform scaled up 4× during the sale), Google Cloud Blog, 9 August 2024: https://cloud.google.com/blog/products/databases/how-flipkart-gets-the-most-out-of-every-byte-with-bigtable

• Read

  Aerospike — Aerospike Database on Kubernetes Enabled 95 Million Transactions Per Second on E-commerce Platform for Festive Sale (Flipkart's in-house Aerospike platform, sustained during The Big Billion Days; the release does not name the year), 4 November 2024: https://aerospike.com/press-release/aerospike-database-on-kubernetes-enabled-95-million-transactions-per-second/

• Book

  Aerospike — Inside Flipkart's journey to 90 million QPS: Scaling with Aerospike and Kubernetes (Aerospike's write-up of a talk by Aditya Goyal and Sahil Jain of Flipkart at the Aerospike Bangalore Summit: 50+ use cases; 200+ clusters; 90 million QPS in aggregate across three data centres; sub-millisecond reads), 4 November 2025: https://aerospike.com/blog/flipkart-journey-90-million-qps

• Talk

  PingCAP — How Flipkart Scales Over 1M QPS with Zero Downtime Maintenance (a write-up of Flipkart's TiDB User Day India 2025 talk: 900 standalone MySQL clusters and their limits; adopting TiDB), 29 May 2025: https://www.pingcap.com/?p=27687

• Read

  CNCF — Flipkart case study (chaos platform; 2,000+ experiments; 6+ misconfigurations found ahead of TBBD 2024; ~20% faster detection, ~25% faster resolution), June 2026: https://www.cncf.io/case-studies/flipkart/

Reporting:

• Read

  Preeti Anand — How Flipkart handles Big Billion Days traffic (Gaurav Arora to Business Standard, September 2026: nearly 1,000× more payment requests at the festive peak; biometric-authenticated transactions with a 12–15% higher success rate than OTP-based ones), DQIndia, 8 October 2026: https://www.dqindia.com/data-and-ai/flipkart-big-billion-days-aerospike-real-time-infrastructure-12636211

• Read

  Business Today (PTI) — Flipkart founders apologise for Big Billion Day glitches (the founders' email; 1.5 million shoppers; ₹600 crore in 10 hours), 7 October 2014: https://www.businesstoday.in/story/flipkart-mega-sale-sachin-bansal-binny-bansal/1/211159.html

• Read

  International Business Times India — Flipkart apologizes to beleaguered patrons over Big Billion Day sale fiasco (the founders' email), October 2014: https://www.ibtimes.co.in/flipkart-apologizes-beleaguered-patrons-over-big-billion-day-sale-fiasco-promises-better-service-610761

• Read

  GSMArena — Xiaomi sells 40,000 Redmi 1S units in India in 4.2 seconds (on Flipkart; more than 250,000 registered), 2 September 2014: https://www.gsmarena.com/xiaomi_sells_40000_redmi_1s_units_in_india_in_42_seconds-news-9528.php

Design note: the deal line, stock holds, checkout, payment handling, price books, search split, promise allocation code, thresholds, dashboards and every number labelled as an assumption or estimate are an illustrative design for the problem, not a description of Flipkart's internal systems beyond what Flipkart and its partners have published. Request rates, orders a second, taps on a deal, conversion and checkout ratios, cache hit rates, hold durations, token counts and the Day 1 brief are assumptions. Rohan Mandal is a fictional customer.

Further Reading#

Related systems to study:

• Read

  IRCTC Tatkal (Bonus Problem 11 in this series): a 10:00 spike on one train's seats, with admission control

• Read

  BookMyShow (Bonus Problem 16): a site-wide waiting room when every seat is the scarce thing

• Read

  Razorpay (Bonus Problem 18): payments, unknown outcomes and reconciliation from the gateway's side

• Read

  Dream11 (Bonus Problem 25): a scheduled spike, forecast-driven capacity, and sharded counters

Course material:

• Read

  The Week 2 capstone, a flash sale for MegaMart, is a smaller version of Deep Dives 2 and 3

Foundational concepts (this course):

• Read

  Week 1, Day 3 — Rate Limiting at Scale

• Read

  Week 1, Day 4 — Hot Keys and Skew

• Read

  Week 2, Day 1 — Timeout Hell

• Read

  Week 2, Day 2 — Idempotency in Practice

• Read

  Week 2, Day 3 — Circuit Breakers

• Read

  Week 3, Day 2 — Transactional Outbox

• Read

  Week 3, Day 3 — Backpressure and Flow Control

• Read

  Week 4, Day 2 — Cache Invalidation

• Read

  Week 4, Day 3 — Thundering Herd

• Read

  Week 4, Day 5 — Multi-Tier Caching

• Read

  Week 5, Day 1 — Consistency Models

• Read

  Week 7, Day 1 — Search Fundamentals

• Read

  Week 10, Day 1 — SLIs, SLOs and SLAs

• Read

  Week 10, Day 4 — Capacity Planning

"Queue the deal, cache the store, and never accept an order against a number that was only true a moment ago."