Design a Currency Exchange System

Clarified whether system covers rate-serving only, trade execution, or both, and asked about freshness/consistency needs
Identified functional requirements: rate lookup, quote/lock, trade execution, history
Called out non-functional targets: latency (reads vs trades), scale (QPS/TPS), consistency model, durability

Proposed separate read path (cache-heavy, high QPS) vs write path (strongly consistent ledger)
Included a rate ingestion/normalization layer pulling from multiple external providers
Used a cache (e.g., Redis with TTL) for rate serving and justified the staleness bound
Included a quote/lock mechanism distinct from live rate lookup
Included a durable, auditable ledger (SQL/ACID) for trade execution

Defined clear endpoints for rate lookup, quote creation, and trade execution with idempotency support
Designed ledger schema with double-entry or equivalent auditable structure
Chose appropriate storage per data type (cache for rates, time-series for history, SQL for ledger)

Discussed idempotency/exactly-once handling for trade execution (unique key, dedupe)
Addressed precision/rounding correctness (fixed-point/decimal, no floats)
Addressed multi-provider rate reconciliation and protection against bad/outlier rates
Explained consistency trade-off: eventual consistency for rate reads vs strong consistency for trades/ledger
Discussed scaling strategy separating high-QPS reads from lower-throughput, strongly-consistent writes

Structured the session within time budget (requirements → high-level → deep dive → wrap-up)
Articulated trade-offs explicitly rather than asserting a single 'right' answer
Gave a concise, confident opening/closing summary of the design

Problem