Flipkart: Big Billion Days, and how Flipkart ships

I keep one authoritative stock count per SKU and warehouse, and reserve with a single atomic conditional update: decrement only where available is greater than zero, and treat zero affected rows as sold out. That removes the read-then-write race. Each reservation gets an ID and a short TTL; if payment fails or the shopper abandons, a sweeper or event releases the unit. For very hot SKUs I can pre-split stock into buckets across shards to avoid one hot row, then rebalance leftovers. Checkout carries an idempotency key so retries never reserve twice. Finally, I reconcile reservations, orders and payments continuously, because the business promise is zero oversell even when parts fail.

I would split the SKU's sellable stock into several buckets, each holding part of the units, stored as separate keys or rows. A reservation picks a bucket at random or by hash and runs the same atomic conditional decrement on it. If that bucket is empty, it tries a few others before returning sold out. Each bucket still can never go below zero, so the total cannot oversell. The cost is a little stranded stock: one bucket may be empty while another holds units. A background rebalancer or a final sweep fixes that. I would also put the virtual queue in front, so the attempt rate stays near what the store was tested for. That way bucketing handles peaks rather than unbounded load.

First, design to make this rare. The hold should outlive the payment timeout plus a margin, and you should not release a hold while a payment attempt is still in flight. Release only on a confirmed failure, an abandon, or a timeout after a status check. If it still happens, the payment is real money, so the order must not be silently dropped. Try to re-reserve from any bucket or fulfilment centre with stock. If that works, confirm normally. If it does not, record the order as paid-unfulfillable, start an automatic refund through the payment service using the same idempotency key, and tell the customer clearly. Track this count in the war room, because a rising number means the hold or timeout settings are wrong.

The client creates a unique key when the shopper first presses Pay and reuses it on every retry, including network retries and double taps. The server stores that key together with a hash of the request: user, cart, amount and reservation IDs. It does this with a unique constraint before calling the payment gateway. If the same key arrives again, the server returns the stored result or the in-progress status, and it does not create a new payment. If the same key arrives with a different payload, it is rejected. The same key, or a key derived from it, goes to the gateway as the merchant order reference, so the gateway also deduplicates. Keys live at least as long as the payment reconciliation window.

I would use the transactional outbox pattern. When payment success is recorded, the same database transaction updates the order to PAID and inserts an outbox row. A relay process reads the outbox and publishes to the durable log, with replication and acknowledgement from multiple brokers. It marks rows as sent only after the publish succeeds. If the relay crashes, it republishes, so consumers must be idempotent by order ID. Separately, a reconciliation job compares gateway settlement reports and payment records with orders. Any payment without a matching confirmed order raises an alert and is repaired or refunded. A dual write straight from the service to both database and broker is what loses orders, so I avoid it.

Autoscaling helps stateless services, but it lags a sudden spike, and the real limits are stateful: databases, hot inventory rows, and payment partners whose capacity we do not control. A virtual queue converts an unbounded spike into a controlled admission rate matching what we load-tested. It is also fairer, since shoppers get a position and a wait estimate instead of random errors, and it blocks bots that would grab stock. I would issue signed admission tokens at the edge, validate them at checkout, and tune the rate live from the war room based on error rates and latency. Autoscaling still runs behind it; the queue just ensures we never exceed proven capacity.

Publicly described practice is that preparation starts months ahead. Teams forecast traffic, plan capacity for compute, databases and partners, and run repeated load tests on production-like setups, fixing bottlenecks each round. Failure drills test what happens when a dependency slows or dies, and every service gets degradation plans and feature flags. Closer to the sale, a feature freeze limits changes to reduce risk. Caches are pre-warmed and payment and logistics partners are aligned on expected volume. During the sale a war room watches technical and business dashboards together, with clear owners and runbooks so decisions like turning off recommendations or slowing queue admission take minutes. Afterwards a review feeds the next year's plan.

There are several layers. Warm caches before the sale and give deal data long or no expiry during the event, with explicit invalidation when a price or deal changes. Add jitter to any TTLs so keys do not expire together. Use request coalescing, also called single-flight: on a miss, only one request rebuilds the key while the others wait or get the slightly stale value. Serve stale-while-revalidate for browse data, because checkout re-verifies price anyway. Keep a local in-process cache in front of the distributed cache for the hottest keys. Protect the database with connection limits and a circuit breaker, so a miss storm degrades into stale pages, not a database outage.

Browsing reads cached price data that can be seconds or minutes stale. That staleness is acceptable for display but not for charging money. At checkout, the order service reads the authoritative price and deal eligibility, including per-user limits, bank offers and the deal window, from the source of truth. It then signs or locks that amount for this checkout. If the price went up or the deal ended, show the new amount and ask the shopper to confirm explicitly. Never charge more silently. If the price went down, charge the lower price. The amount sent to the payment gateway must come only from this verified server-side calculation, never from the client, which also blocks tampering.

When a shopper enters a hot deal, the queue service gives them a position based on arrival time and a signed, short-lived token tied to the user or session. A controller admits positions at a configured rate, matched to the tested backend capacity, and adjusts it from live health signals. Once admitted, the shopper gets a signed admission token. The edge or API gateway checks this token on every protected call, so hitting the origin URLs directly does not work. Tokens expire, are single-use per deal, and are tied to the account, which limits sharing. The waiting page polls cheaply from the edge and shows position or an estimated wait. Anti-bot checks run before a position is issued, not after.

I would state assumptions out loud rather than claim real numbers. Start from expected peak concurrent users and the share who reach checkout in the busiest minute. Convert that to orders per second, then multiply by the fan-out per order: calls to the reservation store, price service, payment and writes. That gives requests per second per dependency. Add headroom for retries and spikes, then size each tier from per-node throughput measured in load tests, not vendor claims. For example, if I assume N checkouts per second, each needing about three inventory operations, the inventory store must handle roughly 3N operations at the target latency. Finally, I set the queue admission rate below the weakest tier's tested limit.

Watch both business and technical signals. Business signals include orders per minute, checkout conversion, payment success rate split by method and bank, reservation success versus sold-out rate, and queue length and wait time. Technical signals include p99 latency and error rates per service, cache hit ratio, database and broker lag, and saturation such as CPU, connections and thread pools. A sudden drop in payment success for one bank or the UPI path is often the first sign of a partner problem. Decisions should follow pre-agreed runbooks with thresholds and named owners. For example, if checkout latency crosses a limit, turn off recommendations and reviews, or reduce the queue admission rate, using feature flags tested during the drills.

The states are CREATED, then RESERVED, then PAYMENT_PENDING, then PAID or COD_CONFIRMED, then ALLOCATED, PACKED, SHIPPED, DELIVERED, with branches for PAYMENT_FAILED, EXPIRED, CANCELLED, RTO and REFUNDED. Each transition is allowed only from specific states. It is applied with a conditional update, such as setting the status to PAID only where the order ID matches and the status is still PAYMENT_PENDING, often guarded by a version number. This makes duplicate callbacks and racing workers harmless, because the second update matches nothing. Every transition also emits an event through the outbox. This makes the order history auditable and lets support, refunds and analytics rebuild the timeline, which matters for disputes.

For a flash sale, I would reserve when the shopper commits to buy, at checkout or on a buy-now action, with a short hold. Reserving at add-to-cart lets many shoppers lock stock they never buy. Scarce deal units then look sold out while sitting in idle carts, which feels unfair and hurts conversion. Holds at checkout are short and tied to an active payment attempt. The cart only shows availability, which is a soft check. For limited deals, you can also enforce per-user quantity limits at reservation time. The trade-off is that a shopper may add an item to the cart and then find it sold out at checkout, so the UI must say clearly that the cart does not hold stock.

Verify every callback's signature first and ignore anything unsigned or for an unknown order. Deduplicate by the gateway's transaction ID and our merchant order reference. Then apply it through the order state machine with conditional updates, so a late FAILED callback cannot overwrite an earlier SUCCESS. Finality rules depend on the gateway, and I treat a success confirmed by a status-check API as authoritative. Do not trust the client redirect alone, because the browser can lie or drop. Return a success acknowledgement to the gateway only after the result is durably stored, so it retries if we crash. Callbacks that arrive after a timeout go to reconciliation.

It takes the confirmed order, finds the centres that hold the reserved units, and scores them. Factors include whether the centre can meet the promised delivery date to the shopper's pincode, its current pick and pack capacity and backlog, shipping cost and distance, and whether the order can ship complete from one centre instead of being split. The trade-off is between speed, cost and load balance. The nearest centre may be overloaded during the sale, so a farther one with spare capacity may meet the promise better. Ideally the reservation is already tied to a centre's stock, so allocation does not have to compete for units again. If capacity is exhausted, it should requeue with backoff.

True exactly-once across services is impractical, so you aim for at-least-once delivery with idempotent consumers. Each event carries a unique ID and the order ID. A consumer records processed event IDs, or uses a conditional state transition, in the same transaction as its side effect. A replayed event then does nothing. Commit the consumer offset only after the side effect is durable. Partition events by order ID so all events for one order are processed in sequence. For external side effects such as SMS or courier booking, pass an idempotency key to the downstream system too. Poison messages go to a dead-letter queue with alerts, instead of blocking the partition.

It replays realistic traffic shapes: a sharp spike at sale start, hot-SKU skew, a realistic mix of browse and checkout, and a mix of payment methods. The traffic runs against production or a production-scale environment, with mocked or sandboxed payment partners and test accounts marked so that orders, inventory and metrics can be filtered out. To be trustworthy, it must use real data volumes and cache states, including cold-cache starts, and the same configurations and versions planned for sale day. Run it repeatedly as code changes, find the first bottleneck, fix it, and run it again. Record the safe throughput for each service, because that number sets the queue admission rate.

Run game days that inject the failures we expect. Kill cache nodes and database replicas. Take down a whole zone. Add latency to a payment gateway or a single bank. Make a downstream service such as recommendations slow rather than dead, because slow is often worse. Pause the event broker to build consumer lag. Also practise operational steps: flipping degradation flags, lowering queue admission, rolling back a release and failing over a database. Each drill checks that alerts fire, dashboards show the issue, runbooks are correct, and people know who decides. Fix the gaps and repeat. The goal is that sale-day incidents feel like rehearsals.

Most outages come from changes, so freezing changes in the run-up means the sale runs on code and configuration that were load-tested and drilled. The capacity numbers stay valid, and the war room knows what is running. The cost is a backlog of features and slower iteration, so the freeze window should be clear and announced early. Exceptions should go through a tight approval path: security fixes, critical bug fixes found in tests, and pre-planned sale-day configuration such as deal setup and flag flips. Even exceptions need testing, a canary rollout and a rollback plan. Changes to configuration and data, like prices and deals, also need review, because those break sales too.

Run a set of checks at checkout. Is COD supported at the destination pincode by the logistics network? Is the order value within allowed limits, and is the item category allowed? Does the account have a history of refusals or returns-to-origin? Are there signals of fraud or bulk reselling, such as many orders to one address? Are any deal-specific restrictions in place, since hot deals may limit COD? COD orders skip online payment, but they still go through reservation and idempotent order creation. Because COD ties up stock and logistics capacity without upfront money, refusals are costly, so the risk rules matter more during a sale.

At delivery, the agent's device records the outcome against the shipment ID: cash collected, digital payment collected, or refused. That event flows to the logistics and order systems and moves the order to DELIVERED with a payment-collected state. The cash the agent holds is deposited by the hub at the end of the day, and digital collections settle through the payment provider. Reconciliation jobs match expected amounts per shipment against deposits and settlements per agent and hub, and they flag mismatches for investigation. Shipments refused at the door become RTO and return to stock. All of this must be idempotent, because delivery devices may sync late or more than once on poor networks.

You need linearizable, atomic single-key updates, so a conditional decrement is correct under concurrency. You need durability, or at least a durable record of reservations, so a node crash does not resurrect sold units. You need low and predictable latency at high write rates on a few hot keys. That could be a strongly consistent database with conditional updates, or an in-memory store running atomic scripts, backed by a durable ledger and reconciliation. Eventually consistent multi-leader stores are risky here, because two regions could each sell the last unit. Keep each SKU's stock owned by one primary location, and accept that availability for that key depends on its primary.

Clients and services should retry with exponential backoff and jitter, under a retry budget, and only on errors that are safe to retry. Every retried write must be idempotent. Put timeouts on every call, shorter than the caller's own deadline, and pass deadlines down the call chain. Use circuit breakers so a failing dependency gets fast failures and time to recover. Apply bulkheads by giving each dependency its own separate pool, so one slow partner cannot exhaust shared threads. At the top, the virtual queue and edge load shedding reduce incoming traffic when health drops. The app should show a friendly retry-later message, not let users hammer a refresh button.

Rank features by how much they matter to buying. Recommendations, personalised widgets, reviews, Q&A, rich search facets and some analytics calls can go first. Search, the product page, cart, checkout, payment and order confirmation must stay. Each degradable feature sits behind a feature flag with a tested fallback, such as a static list, a cached value or hiding the module. Clients must handle a missing response gracefully. Flags should take effect quickly without a deploy, be changed by authorised people only, be audited, and have been flipped during drills. Degrade in steps and watch conversion and latency after each flip.

Prefer changes that can be undone without a deploy. Ship new code behind flags that default off, and roll out gradually with canaries watched against error and latency limits. Keep the previous build ready, so rollback is a quick traffic switch or redeploy of a known artifact. Make database schema changes backward compatible using the expand-and-contract approach, so the old code still works on the new schema. Version configuration and deal data, with a one-step revert. In the war room, a named owner can roll back without debate when a threshold is crossed, and the team investigates afterwards. Rollback steps are practised before the sale.

Card data should not touch our servers in raw form. Use the payment gateway's hosted fields or SDK, and use network or issuer tokens for saved cards, as RBI's card-on-file tokenisation rules require. That keeps most systems out of PCI DSS scope. UPI and EMI flows exchange references, not credentials. Encrypt personal data such as addresses and phone numbers in transit and at rest. Restrict access by role, and mask data in logs and support tools. For delivery, share only what the agent needs, and consider masked calling. Follow India's DPDP Act on purpose limitation and retention. Verify webhook signatures, and keep payment amounts server-side only.

EMI adds eligibility and offer logic. It depends on the issuer or lender, card type, tenure, minimum order value and whether a no-cost EMI deal applies, where the interest is offset by discounts. These rules should be calculated server-side at checkout, alongside price re-verification, so the shopper sees the exact total, EMI amount and any fees before paying. The payment itself still uses the same idempotency key, hold and callback handling, but authorisation may take longer or need extra steps. The hold timeout must cover that. Card-less or pay-later EMI depends on a lender's approval, so it adds an external dependency that needs its own timeout, circuit breaker and fallback.

The inventory table has one row per SKU, per fulfilment centre, per bucket, holding available and reserved counts and a version number. A reservation record holds the reservation ID, SKU, centre, quantity, user, order ID, status (HELD, CONSUMED or RELEASED) and an expiry time. The order record holds its ID, user, line items with locked prices, total, payment method, idempotency key with a unique constraint, state and version. A payment record holds the attempt ID, order ID, gateway reference, amount, status and timestamps. An outbox table stores events waiting to publish. Reserving inserts the hold and decrements available stock atomically. Consuming or releasing moves the hold's status once, guarded by a conditional update.

Each hold has an expiry time. A sweeper scans for holds still in HELD status past their expiry, indexed by expiry time and sharded across workers. For each one, it runs a conditional update from HELD to RELEASED, and only if that succeeds does it add the unit back to stock. This makes double release impossible. Before releasing a hold whose payment is pending, it asks the payment service for status, so a payment that just succeeded is not undone. Delayed-queue messages or store-level TTL events can trigger releases sooner, but the sweeper remains the safety net. Releasing too slowly hides real stock, while releasing too eagerly creates paid-but-no-stock cases.

Combine several signals rather than relying on one. Use rate limits per IP, device and account. Check reputation lists, and use device and browser fingerprinting and app attestation where available. Look at behaviour such as inhuman speed, scripted paths or direct calls to checkout APIs without page loads. Use challenges such as a CAPTCHA only for suspicious traffic, so normal users are not slowed. Account-level controls matter for deals: verified accounts, per-user purchase limits and signed queue tokens. Watch for false positives, because mobile carriers in India often share IPs across many users through carrier-grade NAT, so strict per-IP limits can block real shoppers.

Stateless services run across zones behind load balancers, so losing a zone means losing capacity, not function. Capacity planning should keep enough headroom to absorb that loss at peak. Stateful pieces are harder. Databases use synchronous replication within a region for failover without data loss. Inventory keys keep a single primary at a time to avoid split-brain oversell, and failover is fenced, so the old primary cannot accept writes. Cross-region active-active for stock is risky. The event log replicates across zones with acknowledgements from several brokers. All of this needs to be drilled, because untested failover often fails exactly when it is needed.

Show a clear pending state: the order is being confirmed, do not pay again, and we will notify you. Also show a way to check status. Keep the shopper on a status page that polls our server, not the gateway. This matters technically because confused users retry. They pay again with a new method, open another tab or call support, which creates duplicate payment attempts and load. The idempotency key and a rule allowing one active payment per order or reservation limit the damage. A final notification by app push, SMS or email once the status resolves, and an automatic refund of any duplicate charge, keep trust high.

1. AA single atomic conditional decrement that fails when stock is zeroCorrect answer
2. BCache stock in the CDN and decrement it there
3. CAllow oversell and cancel extra orders later
4. DRead stock, check it is positive, then write the new value

Why: An atomic conditional update makes the check and write one operation, so concurrent requests cannot both pass the check. Read-then-write has a race window.

1. AIt equals the user ID
2. BIt is a timestamp rounded to the second
3. CIt is generated fresh by the server on every request
4. DIt is created once per checkout attempt and reused unchanged on every retryCorrect answer

Why: Deduplication only works if every retry carries the same key. A fresh key per request makes each retry look like a new payment.

1. AWrite to the database, then publish to the broker in the same function
2. BTransactional outbox with a relay that publishes committed outbox rowsCorrect answer
3. CPublish to the broker first, then write to the database
4. DRely on client retries to resubmit the order

Why: The outbox row commits atomically with the order state, and the relay republishes until it succeeds. That removes the dual-write gap.

1. ACache the stock count and decrement it in the CDN
2. BDrop the condition and let stock go negative, fixing it later
3. CRead stock from a replica before writing
4. DSplit stock into buckets, each updated with an atomic conditional decrementCorrect answer

Why: Each bucket still enforces stock greater than zero atomically, so the total cannot go negative, and writes spread across keys.

1. AShip the order assuming payment succeeded
2. BMark the order failed and release stock immediately
3. CRetry the debit with a new transaction
4. DKeep the order pending, poll or reconcile status, then confirm or releaseCorrect answer

Why: UPI confirmations can be delayed, so a pending state with status reconciliation avoids both lost paid orders and double charges.

1. AA conditional state transition, such as PAYMENT_PENDING to PAID, deduplicated by transaction IDCorrect answer
2. BIgnore all callbacks and trust the client redirect
3. CCreate a new order for each callback
4. DProcess them in parallel and let the last one win

Why: Conditional transitions make repeats do nothing, and deduplication by gateway transaction ID stops double processing.

1. ATo slow down bots
2. BBecause CDNs cannot cache prices
3. CTo apply GST twice
4. DBrowse caches can be stale, and the charge must come from the authoritative priceCorrect answer

Why: Cached display data may lag behind price changes, so only a server-side verified price should set the amount charged.

1. AMaximise the number of concurrent checkouts regardless of health
2. BReplace the need for rate limiting at the edge
3. CRandomise which users get deals
4. DMatch incoming load to the capacity the backend was tested forCorrect answer

Why: Admitting at a tested rate keeps downstream services inside safe limits and gives orderly waiting instead of errors.

1. ACheck whether the user has a cart
2. BTrust a query parameter named admitted=true
3. CVerify a signed, expiring admission token tied to the userCorrect answer
4. DCheck the Referer header

Why: A signed, short-lived token bound to the account cannot be forged or easily shared, so the queue cannot be bypassed.

1. AProcess each event only from memory
2. BRequire the broker to guarantee exactly-once delivery across all services
3. CMake consumers idempotent using event or order IDsCorrect answer
4. DDisable consumer retries

Why: At-least-once delivery plus idempotent consumers is the practical way to get the effect of exactly-once processing.

1. AFulfilment centres cannot accept synchronous calls
2. BIt removes the need for inventory data
3. CEvent logs are cheaper than databases
4. DIt keeps checkout fast and lets allocation retry and rebalance without losing ordersCorrect answer

Why: Decoupling via a durable log means checkout only has to record the order, while allocation can scale, retry and optimise separately.

1. AWhen the cart page is refreshed
2. BImmediately when the hold timer fires
3. COnly after a payment status check confirms failure or abandonmentCorrect answer
4. DNever; holds are permanent

Why: Releasing during an in-flight payment can create a paid order with no stock, so check payment status first.

1. ASet all keys to expire at the same moment
2. BDisable the cache during the sale
3. CLet every request rebuild the key from the database
4. DRequest coalescing (single-flight) with stale-while-revalidateCorrect answer

Why: Only one request rebuilds the key while others get a stale value or wait, so the database is not flooded.

1. ATo reduce memory usage
2. BTo encrypt keys
3. CTo make cached data more accurate
4. DTo prevent many keys from expiring at the same timeCorrect answer

Why: Spreading expiry times avoids synchronised misses that would hit the origin all at once.

1. ABots get faster
2. BReal users behind carrier-grade NAT sharing an IP are blockedCorrect answer
3. CCDN costs drop to zero
4. DPayments are charged twice

Why: Many mobile users share public IPs through carrier NAT, so strict per-IP limits cause false positives.

1. AA new recommendation algorithm
2. BA reviewed critical security fix with canary and rollback planCorrect answer
3. CA database engine migration
4. DA redesign of the checkout UI

Why: Freezes allow tightly controlled exceptions such as critical fixes. Large untested changes are what freezes exist to stop.

1. AUse last-write-wins with no checks
2. BLock the whole orders table
3. CLet the client decide the state
4. DUse a conditional update on the current state or versionCorrect answer

Why: Optimistic conditional updates let only one valid transition succeed, without heavy locks.

1. AThe amount in the client request
2. BThe server-side verified total computed at checkoutCorrect answer
3. CThe cached browse price
4. DThe amount the gateway proposes

Why: Server-computed totals stop tampering and stale-cache charges.

1. AEmail card details to the customer
2. BStore full card numbers encrypted in the merchant database
3. CUse tokenised card-on-file references instead of storing card numbersCorrect answer
4. DStore the CVV for convenience

Why: RBI's card-on-file tokenisation rules stop merchants from storing actual card data, so tokens are used.

1. ARemove the product page cache
2. BIncrease timeouts so calls eventually finish
3. CBulkhead pools, short timeouts and a circuit breaker with a fallbackCorrect answer
4. DRetry the calls more aggressively

Why: Isolation and fast failure stop a slow dependency from taking down critical paths.

1. ARetry forever until success
2. BRetry only non-idempotent writes
3. CImmediate retries in a tight loop
4. DExponential backoff with jitter and a retry budgetCorrect answer

Why: Backoff with jitter and budgets prevents retry storms that make an overload worse.

1. AThe customer's payment method only
2. BRandom choice for fairness
3. CStock location, delivery promise and centre capacityCorrect answer
4. DOnly the alphabetical order of centres

Why: Allocation weighs where stock is, whether the promise can be met, and current pick and pack capacity.

1. APayment gateways forbid it
2. BCarts cannot store SKUs
3. CIdle carts lock scarce units, making deals look sold out unfairlyCorrect answer
4. DIt makes oversell guaranteed

Why: Many cart adds never convert, so early holds strand limited stock away from real buyers.

1. ASchema-less documents
2. BEventual consistency across multiple leaders
3. CAtomic, linearizable conditional update on the keyCorrect answer
4. DFull-text search

Why: Atomic conditional updates on one authoritative copy are what make oversell impossible.

1. AIt is too slow to read
2. BTwo regions can each sell the last unit before they syncCorrect answer
3. CRegions cannot store integers
4. DCDNs block it

Why: Without a single owner or consensus, concurrent writes in each region can oversell.

1. AIt replaces signature checks
2. BGateways may deliver the same callback more than onceCorrect answer
3. CIt compresses logs
4. DIt speeds up the UI

Why: Webhooks are typically at-least-once, so repeats must be recognised and ignored.

1. AMove it to return-to-origin and restock the unit when it is received backCorrect answer
2. BCharge the customer's card automatically
3. CDelete the order record
4. DMark it delivered and close it

Why: Refusals become RTO shipments, and the unit returns to sellable stock after receipt.

1. ARunning it once on a small staging cluster
2. BProduction-like data, configuration and traffic shape, repeated after changesCorrect answer
3. CUsing only read traffic
4. DTesting each service alone with no dependencies

Why: Results only predict sale-day behaviour if the environment and load mirror reality and are re-run as code changes.

1. ARestart all databases
2. BTurn off payment signature verification
3. CDeploy a new hotfix immediately
4. DLower queue admission or flip flags to degrade non-critical featuresCorrect answer

Why: Pre-tested flags and admission control reduce load quickly and safely, without risky changes.

1. ABecause databases require it
2. BTo speed up queries
3. CSo rollback to the previous build still worksCorrect answer
4. DTo reduce disk usage

Why: Expand-and-contract changes let old and new code run on the same schema, which keeps fast rollback possible.

1. AThe hold should be shorter than the payment timeout
2. BThe hold should outlive the payment timeout plus a marginCorrect answer
3. CThey are unrelated
4. DHolds should have no timeout

Why: If holds expire before payments resolve, successful payments can lose their stock.

1. ATo encrypt the events
2. BTo make every partition the same size regardless of traffic
3. CTo avoid needing consumers
4. DTo keep all events for one order in sequenceCorrect answer

Why: A partition preserves order, so keying by order ID processes that order's events sequentially.

1. AComparing cache hit ratios
2. BComparing gateway settlement reports against order and payment recordsCorrect answer
3. CChecking CDN logs
4. DCounting page views

Why: Matching settlements to orders finds orphaned payments, which are then repaired or refunded.