Design a bookkeeping/ledger service for a payments platform (e.g., Stripe). Stripe merchants sell goods/services online; every time a customer makes a purchase, money is collected on behalf of the merchant, and periodically the merchant is paid out an aggregated amount. Other teams handle the actual sending/receiving of money, credit card charging, and fraud detection. Your task is to build the Ledger service that: (1) records all financial activity (money sent or received on behalf of a merchant), and (2) supports querying the account balance for a given merchant. The system should expose at minimum two APIs: a Record Transaction API and a Get Account Balance API. Interviewers expect API-level detail (request/response schema, data modeling), database schema design, and discussion of scalability and reliability concerns — not just high-level architecture. Key deep-dive topics include: how to model money/price objects, idempotency key design to prevent duplicate transactions, and scalability of balance queries.
Naive approach with serious trade-off — being authored.
Solid baseline with reasonable trade-offs — being authored.
Production-grade approach with explicit trade-off rationale — being authored.
Naive approach with serious trade-off — being authored.
Solid baseline with reasonable trade-offs — being authored.
Production-grade approach with explicit trade-off rationale — being authored.
Naive approach with serious trade-off — being authored.
Solid baseline with reasonable trade-offs — being authored.
Production-grade approach with explicit trade-off rationale — being authored.
Cover happy path. Clarify scope. Identify the obvious bottleneck. Pick a reasonable storage and reasonable scaling approach.
All of the above plus: explicit failure handling, durability vs latency trade-offs, choose the right batching/caching strategy, articulate why.
All of the above plus: organizational concerns (rollout, migration, on-call), quantitative analysis, multi-region considerations, what could go wrong with the proposed solution at 10x scale.
Observed variants: Base: Record transaction + get balance APIs only | With idempotency key deep-dive | With money/price object modeling deep-dive (~50% of interview time)
What you just read — canonical solution, follow-up arc, what passing candidates actually did — exists for all 70 Stripe questions, refreshed monthly from new candidate reports.