Design concurrency-safe shared payment account API
Prevent Double-Spending When Two Users Pay Simultaneously from the Same Account
Context
You are designing a payments service where multiple clients may initiate payments at the same time against a shared account. The system must maintain a correct balance and prevent double-spending even under failures, retries, and high concurrency.
Task
Design the API and backend to ensure correctness and durability. Cover:
-
Request/response design, including status codes and error semantics.
-
Idempotency keys and how they are stored/enforced.
-
Concurrency control strategy (optimistic vs. pessimistic), transactions, and isolation levels.
-
Consistency guarantees to clients and internally.
-
Retry strategy and failure handling.
-
Monitoring, alerting, and observability.
-
Scaling to very high concurrency and massive request volumes.
Assume a typical service + database architecture. You may make minimal, explicit assumptions as needed.
Constraints & Assumptions
-
Preserve the scope, facts, inputs, and requested outputs from the prompt above.
-
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
-
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.
Clarifying Questions to Ask
-
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
-
State explicit assumptions before making sizing or architecture decisions.
-
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers
-
A scoped requirements summary with concrete non-goals and success metrics.
-
API, data model, architecture, consistency, capacity, and operations.
-
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
-
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions
-
What breaks first at 10x traffic or data volume?
-
How would you degrade gracefully during dependency failures?
-
What metrics and alerts would prove the design is healthy after launch?