In this article
Before you start
This page is one stop on the interview process, stages and rounds path.
Why interviewers ask this
A manager who cannot reason about a design cannot judge the designs their team brings them, and a manager who only draws boxes cannot lead a room. The round tests both: technical judgment and the way you run the conversation.
The prep site Exponent, a third-party guide and not an employer, reports that Meta's engineering manager system design interview appears twice: once as a 45-60 minute technical screen and once as a 45-minute round inside the loop. The same guide says the people management and project retrospective rounds produce the strongest hire signal, so design is one signal among several. The Meta engineering manager interview rounds page covers the full loop.
A weak answer lists components. A strong answer states assumptions early, outlines before going deep and narrates trade-offs, which is the advice in the same guide.
System design for managers from first principles
- Service level indicator (SLI)
- A service level indicator is a measured number that describes how a service behaves, such as the share of requests that succeed in a month. It is the raw measurement; targets and promises are set against it.
- Service level agreement (SLA)
- A service level agreement is a promise to the people using a service that it will meet stated levels, such as availability, over a stated period, with a penalty if it fails. It is normally looser than the internal objective.
In plain words
Think of a restaurant kitchen planning for a busy Saturday. The manager does not cook every dish. She asks how many guests are coming, decides how fast tickets must come out, and plans what happens when an order is sent twice. The analogy breaks in one place: a kitchen can see its queue, while a service must infer it from numbers.
In one precise sentence, a manager system design answer is a short, ordered argument: scope, safe operations, reliability targets, load, then the trade-offs you accept.
The running example is a payment gateway. A payment gateway is a service that accepts a payment request from a merchant and passes it to the banks and card networks that move the money. It is a popular prompt because a repeated request can charge a person twice.
Step 1: Clarify the scope and state your assumptions
A manager answer starts by stating scope and assumptions out loud. Ask who calls the service, which payment types count, and what must never happen, such as charging twice. Then say your assumptions as assumptions, not as facts.
Input: a vague prompt. Output: a short list of scope and numbers you will design against. For example, say "I assume card payments only, one currency, and about ten million payments a day (illustrative)." The interviewer can correct you, and the correction is information.
This step is also where you lead. Say how you will use the time: assumptions, interface, targets, load, then trade-offs. The Exponent guide gives the same advice: state assumptions early and outline before going deep. You now have a shared problem; the next step makes the dangerous operation safe.
Step 2: Make the payment call safe to retry
An idempotency key makes a retried payment return the first result. Without one, a client whose connection drops after sending a payment cannot know whether the charge happened, so retrying risks a second charge and not retrying risks a lost payment.
Stripe's documentation, as of October 2026, describes one implementation: for its v1 API, Stripe saves the status code and body of the first request with a given key once the endpoint starts executing, and retries with that key return the saved response, including server errors; its v2 API instead completes failed work on retry where it can. For its v1 API, all POST requests accept keys, while keys sent on GET and DELETE requests have no effect.
Input: a request with a key. Output: one charge, however many times the request arrives. The trade-off to name is storage: the service must keep keys and results for some window, tied to how long clients keep retrying.
Step 3: Set reliability targets and a downtime budget
A manager answer sets the reliability targets as requirements, not afterthoughts. The Google Cloud reliability team advises that SLIs, service-level objectives (SLOs) and SLAs belong in the requirements of a new system. Their example is an availability SLA of 99.9% over one month with an internal SLO of 99.95%. That service level objective (SLO) is stricter than the customer promise, which leaves room to react before a penalty applies.
A downtime budget is the number of minutes a service may be down in a period without missing its target. A 30-day month has 43,200 minutes.1 A 99.9% target allows 43.2 minutes of downtime in a 30-day month, and a 99.95% target allows 21.6 minutes, so the gap between SLO and SLA is 21.6 minutes of room.1
| Availability target | Downtime allowed in a 30-day month |
|---|---|
| 99% | 432 minutes |
| 99.9% | 43.2 minutes |
| 99.95% | 21.6 minutes |
| 99.99% | 4.32 minutes |
Text description of the diagram
- A 99.9% target allows 43.2 minutes of downtime in a 30-day month.
- A 99.95% target allows 21.6 minutes.
Say the cost aloud: each stricter target needs more redundancy, more on-call effort and slower releases.
Step 4: Estimate the load and name the trade-offs
Peak load is a multiple of average load, so size the service for the peak. The peak factor is the ratio of the busiest period's request rate to the daily average. Both inputs below are illustrative assumptions, not measurements.
With ten million payments a day, the average is 115.74 transactions per second (TPS), and a peak factor of five gives about 580 TPS.1 If an illustrative 100 bytes are stored per idempotency key and result, ten million keys a day is about 1 GB of key storage a day.1 The numbers show where to look first: the write path and the key store, not the web tier.
Then name the trade-offs you accept. For example: favour consistency over availability on writes, because a wrong charge costs more than a short refusal; or accept a larger key store to buy safe retries. Finish with the leadership layer: who owns on-call, how you roll out, and how you would know the targets are met.
Step-by-step description
- State scope and assumptions out loud.
- An idempotency key returns the first result.
- Set the objective stricter than the promise.
- Size for peak load and name trade-offs.
- A manager answer starts by stating scope and assumptions out loud.
- An idempotency key makes a retried payment return the first result.
- The internal objective is stricter than the customer promise.
- Peak load is a multiple of average load.
How technical does a manager system design round get?
A manager system design round uses the same design shape as the individual-contributor round, but a strong answer spends less time on the internals of one component and more on structure, risk and people. The Exponent guide advises stating assumptions early and outlining before going deep, so you lead the structure of the discussion. Beyond the boxes, say how you would staff and phase the build: a thin first release that handles payments safely, then extras such as more currencies, with a named owner for each part.
Name cross-team dependencies, such as a fraud team or a bank-integration team, and what you need from each and by when. Say which parts you would buy rather than build, such as card processing through a provider, and which you keep in house. Finish with operational readiness: on-call, alerts on your targets and a rollout you can reverse.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
Design a payment gateway. Where do you start?
I would start by confirming scope: card payments only, one currency, and what we promise about duplicate charges. I would state my volume assumptions out loud, then propose an interface where every create-payment call carries an idempotency key, so a client that times out can retry and receive the first result instead of a second charge. I would set an internal reliability target stricter than the customer promise, so I have a downtime budget before we breach it. Then I would size peak load, name the write path as the first bottleneck, and say which trade-off I accept: consistency over availability on writes. Last, I would say who owns on-call and how we roll out.
The spoken structure is scope, safe retries, targets, load, trade-off, ownership. What makes it Staff-level is that it names the failure first, sets the internal objective stricter than the customer promise, and ends with who runs it.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Correctness | Boxes with no failure handling | Handles timeouts and duplicate requests | Names the failure first and the design that contains it |
| Depth | Names technologies | Explains one component end to end | Sizes the bottleneck and says what breaks next |
| Trade-offs | None stated | States one trade-off | Names what you give up and when you would revisit |
| Communication | Silent, then a drawing | States assumptions and an outline | Narrates, checks the interviewer's priorities, adjusts |
| Leadership | Not mentioned | Mentions the team | Covers ownership, rollout and how targets are measured |
Three variants of this question
Have you dealt with similarly large resources and traffic before?
Answer with the largest system you have run, in units, and say plainly if the prompt is bigger. Then show how you would reason about the gap: what you would measure and what you would change first.
Tell me about a system your team scaled and what decisions you made as a leader.
Pick one system. State the problem, the two options you weighed, what you decided, who you had to convince and the measured result. The interviewer wants your decision, not the team's.
How would you handle a really tight project?
Handle a tight project by cutting scope before moving dates, naming the biggest risk, and agreeing the trade-off with stakeholders in writing. In the payment gateway, you would drop multi-currency support first and protect idempotency, because a duplicate charge costs more than a missing feature.
Common mistakes
- "SLA and SLO are the same thing." (wrong) The SLA is the promise to customers; the SLO is a stricter internal target. (right) "We run to a stricter objective so we react before the promise is at risk."
- "Retrying a failed payment is dangerous, so we never retry." (wrong) With an idempotency key, a retry with the same key never creates a second charge; whether a stored error is replayed is one provider's choice (Stripe's v1 API replays it, its v2 API completes the work where it can). (right) "Clients retry with the same key, and the service returns the stored outcome instead of charging again."
- "Every call needs an idempotency key." (wrong) Stripe's documentation says keys have no effect on
GETandDELETE. (right) "Keys protect operations that are not naturally idempotent, such as creating a payment withPOST;GETandDELETEare idempotent by definition, so a key on them has no effect." - "This round is the same as the individual-contributor round." (wrong) The format is similar, but the emphasis is on assumptions, trade-offs and leading the discussion. (right) "I will state assumptions, outline, then narrate trade-offs as I go."
Follow-up questions
What happens if a payment request times out and the client retries?
The client sends the same request with the same idempotency key. The service finds the stored result for that key and returns it, so there is one charge however many times the request arrives.
What is the difference between an SLO and an SLA?
An SLO is the internal target and an SLA is the customer promise with a penalty. Google Cloud's example sets a 99.9% SLA over a month against a 99.95% SLO.
Do you need an idempotency key on every call?
No. Keys protect operations that are not naturally idempotent, such as creating a payment with POST. GET and DELETE are idempotent by definition, so Stripe's documentation says a key on them has no effect.
How is a manager system design round different from the individual-contributor round?
The design content overlaps, but a strong manager answer leads the discussion, states assumptions early and narrates trade-offs. Expect people and project rounds to carry weight too; see the interview loops overview.
Does the round change at an AI lab?
Prompts can shift toward model-based systems. Check each company's own process page, such as how the Anthropic interview process works and OpenAI interview questions and process, and practise with the AI engineer questions and the forward deployed and applied AI engineer rounds.
- Open with scope and stated assumptions, then outline before going deep.
- An idempotency key makes a retried payment return the first result.
- The internal objective is stricter than the customer promise; the gap is your reaction time.
- Size for peak load, and name the trade-off you accept.
- Finish with ownership: on-call, rollout and how targets are measured.
Sources
- SRE at Google: SLOs, SLIs, SLAs, oh my (Google Cloud blog, CRE team) — Google Cloud, 28 Jun 2018
- Idempotent requests (Stripe API documentation) — Stripe, 26 Oct 2026
- Meta Engineering Manager Interview Guide — Exponent (third-party prep site), 1 Oct 2026
