An interviewer says - festive season starts in six weeks. Our payments gateway normally does 3000 transactions per second and marketing expects 10x on one evening. Give me the capacity plan. What do you ask first and what do you deliver?

What the interviewer is testing

Whether you plan capacity for a system you do not fully control. A payments gateway in the mould of Razorpay or a card acquirer is mostly other people's capacity: issuing banks, card networks, a national instant-payment rail, fraud scoring, and a ledger that must stay consistent. Scaling your own fleet is the easy third of the problem, and a candidate who only does that has missed it.

The clarifying questions that change the answer

• Is the 10x a peak rate or an evening's volume? Ten times the transactions spread over four hours is a different system from ten times the rate for twenty minutes. Ask for the expected arrival curve and the duration above 5x.
• What do the downstream rails actually permit? Each bank connection has a negotiated throughput and a concurrency cap, and some degrade well before refusing. The binding constraint is almost always the slowest issuer, not your own compute, and no amount of horizontal scaling moves it.
• What is the failure policy? If a bank saturates, do we queue, decline fast, or fail over to another rail? That is a product and compliance decision with revenue attached, and it must be made before the evening, not during it.
• What must stay consistent under load? Authorisation, capture and refund have different tolerances. Ledger writes and idempotency guarantees are not negotiable; receipts, webhooks to merchants and analytics are.

A strong answer's arc

1. Model per dependency, not per service. One row per downstream rail: permitted rate, observed p99, behaviour at saturation, and what we do when it saturates. This document is the plan; the fleet sizing is an appendix.
2. Set the admission policy from those limits. Per-rail token-bucket pacing with priority classes, so a marketing-driven retry storm cannot crowd out an in-flight authorisation. Shed at the edge, in the user's own journey, where a clear "try again" is honest, rather than deep inside where it becomes a timeout.
3. Make the asynchronous path the default. Merchant webhooks, receipts, loyalty updates and reporting move to a queue with its own budget, so the synchronous path holds only what the customer waits for.
4. Size the fleet from measured per-transaction cost at the target concurrency, pre-scale rather than autoscale for the evening, and hold headroom for the loss of one zone.
5. Rehearse against production. A tagged load test on the live path with writes diverted to shadow tables - the approach Alibaba has described for its Singles' Day preparation - is the only way to discover the connection pool, the rate limiter and the third-party timeout that only appear together.
6. Define the degradation ladder and who may pull each rung, and write the reconciliation plan for whatever the evening leaves inconsistent.

Common weak answers

• "Autoscale and add replicas." Reactive scaling is too slow for a 20-minute ramp and does not touch the bank limits that bind.
• "Add retries so nothing is lost." Retries against a saturated rail are the storm. Retry budgets, idempotency keys and a dead-letter path, or nothing.
• "We will load test the week before." A test that only drives your own services validates the part that was never the constraint.

What a strong answer adds

The organisational layer: a named owner per rail with that bank's contact on the evening, a pre-agreed decline policy signed off by the business, a cost envelope for the pre-scale, and a post-event reconciliation window staffed in advance because the ledger, not the latency graph, is what the company will be judged on the next morning.