System design guide
The Stripe system design interview: reliability, APIs and prep
Stripe's interviews are known for being practical: real APIs, real edge cases, and design questions where the hard part is never losing or duplicating money. If other companies test scale, Stripe tests correctness under failure.
Stripe's loop varies by role and changes over time. This page summarises public candidate reports and prep guides (sources at the end); confirm the format with your recruiter.
What the loop includes
Reports differ in detail, but a common pattern for experienced engineers is: coding rounds, an integration round (practical work against an API or codebase), a bug-squash style debugging round in some loops, one or two design rounds (distributed systems and/or API design), and a behavioural round. Design rounds are roughly 45–60 minutes.
Why reliability dominates
In most consumer products, a dropped message is an inconvenience. At a payments company, a lost message is a lost payment and a duplicate is a double charge. Stripe's design questions reportedly push hard on:
- Idempotency at every boundary: client to API, API to internal services, services to card networks and banks.
- Partial failure: timeouts where you don't know whether the other side acted. "Unknown" is a state, not a failure.
- Exactly-once effects from at-least-once delivery plus de-duplication.
- Auditability: append-only records, ledgers, and reconciliation against external reports.
- Consistency: strong where money moves, eventual where it's safe. See consistency models and CAP.
Prompts candidates report
| Prompt | Where the depth is | Our guide |
|---|---|---|
| Payment processing system | State machine, idempotency, ledger, outbox, reconciliation | Design a payment system |
| API rate limiter | Per-key limits, atomic counters, fail-open vs fail-closed | Design a rate limiter |
| Webhook delivery | Retries with backoff, signing, ordering, dead letters | Notification system (same patterns) |
| Transaction log / ledger APIs | Append-only storage, balances, pagination, consistency | Payment system, ledger section |
| Metrics or billing aggregation | Streaming counts, late events, exactness | Top-K and aggregation |
API design: what to get right
- Resources and verbs: nouns for resources (
/payments,/refunds), clear state transitions as sub-actions (/payments/{id}/capture). - Idempotency keys on every mutating request, with defined behaviour for concurrent duplicates.
- Errors: typed error codes, which errors are retryable, and what partial success looks like.
- Pagination: cursor-based, stable under concurrent inserts.
- Versioning: how you change the API without breaking existing integrations.
- Money: integer minor units plus currency, never floats.
Example: the first 15 minutes of "design webhook delivery"
- Scope (3–5 min). Merchants register endpoints and event types; every relevant event must be delivered at least once, signed, and retried for days if the endpoint is down. Ask about ordering guarantees (usually none across events; include timestamps and let merchants fetch current state).
- Estimates (3 min). Events per second at peak, fan-out per event (number of endpoints subscribed), and how much backlog builds if a large merchant's endpoint is down for a day.
- Diagram (5–7 min). Events written via a transactional outbox, a dispatcher creating one delivery task per endpoint, per-endpoint queues, delivery workers with exponential backoff, and a dead-letter state merchants can replay.
- Deep dive. Isolation (one slow endpoint mustn't delay others), signatures and replay protection, and idempotency on the receiving side via event IDs.
Prep plan
- Work through the payment system design until you can explain the idempotency flow, the ledger entries for a capture and a refund, and what happens on a PSP timeout.
- Design a webhook delivery system and a rate limiter, focusing on failure handling.
- Practise one API design end to end (resources, endpoints, errors, pagination, versioning).
- For the integration round, practise reading unfamiliar API docs quickly and writing small, well-tested clients with proper error handling.
Sources
- Exponent, "Stripe system design interview": tryexponent.com/blog/stripe-system-design-interview
- techinterview.org, Stripe bug bash and API design rounds: techinterview.org
- PracHub, Stripe integration round guide: prachub.com
- Engineering Enablement, approaching the Stripe system design interview: engineeringenablement.substack.com
FAQ
What is Stripe's integration round?
Candidates describe a practical exercise: working against an unfamiliar API or codebase with documentation, often with internet access for syntax lookups, to build or fix something small but realistic. It rewards reading docs carefully, handling errors, and writing clean, tested code.
Is there a separate API design round?
Some candidates, particularly for senior roles, report one. It focuses on resource modelling, idempotency, versioning, pagination, authentication, and error design rather than distributed-systems scale.
Do I need payments experience?
No, but you should understand the basics: authorisation vs capture, idempotency keys, webhooks, double-entry ledgers, and reconciliation. Our payment system guide covers all of them.