Historical FX-Rate Service – System Design
Overview
This question evaluates system design and product decision-making skills, focusing on designing a high-throughput, low-latency historical FX-rate service with emphasis on time-series data modeling, caching and consistency trade-offs, scalability, and operational monitoring; the domain is product-focused system design (Product / Decision Making).
System Design: Historical FX Rates Service (10k QPS)
Background
You are designing an internal service for engineers and analysts to fetch historical currency exchange rates (e.g., USD→EUR) for analytics, backfills, and financial reporting. The service must be highly available, low latency, and cost-efficient, and will be consumed by internal applications and data pipelines.
Assume the service primarily supports read traffic (10k QPS) with occasional corrections/backfills from upstream providers. Historical rates are mostly immutable but can be revised.
Requirements
Describe a design that covers:
-
APIs
- Read endpoints for point-in-time and time-series queries.
- Optional write/ingestion endpoints for internal data pipelines.
- Versioning, pagination, auth, rate limits, and error handling.
-
Data Model
- Entities, fields (e.g., pair, timestamp, rate types), precision, versioning for corrections, and indexing.
-
Storage Layer
- Hot vs. cold storage choices; partitioning/sharding; replication; retention.
-
Caching Strategy
- Layers (in-process, distributed, CDN if applicable), keys, TTLs, invalidation, and precomputation.
-
Consistency Requirements
- Freshness expectations, handling of corrections/backfills, snapshot semantics, and trade-offs (strong vs. eventual consistency).
-
Scalability Plan
- Capacity estimates for 10k QPS, autoscaling, multi-region strategy, and failure handling.
-
Monitoring and Operations
- SLIs/SLOs, alerts, tracing, data quality checks, and runbooks.
State reasonable assumptions where needed to make the problem concrete.
Solution
Login required