Historical FX-Rate Service – System Design

Quick Overview

Practice designing a historical FX-rate service for 10k QPS with APIs, data models, precision, versioned corrections, hot and cold storage, caching, consistency, snapshot semantics, scalability, multi-region reliability, monitoring, and operations.

Historical FX-Rate Service – System Design

Company: Google

Role: Product Manager

Category: Product / Decision Making

Difficulty: hard

Interview Round: Onsite

##### Question Design an internal tool that returns historical currency-exchange rates and supports 10 k QPS. Describe the APIs, data model, storage layer, caching strategy, consistency requirements, scalability plan, and monitoring approach.

Quick Answer: Practice designing a historical FX-rate service for 10k QPS with APIs, data models, precision, versioned corrections, hot and cold storage, caching, consistency, snapshot semantics, scalability, multi-region reliability, monitoring, and operations.

|Home/Product / Decision Making/Google
Google logo
Google
Jul 4, 2025, 8:28 PM
hardProduct ManagerOnsiteProduct / Decision Making
21
0

System Design: Historical FX-Rate Service

Design an internal service for engineers and analysts to fetch historical currency exchange rates for analytics, backfills, and financial reporting. The service should support roughly 10k read QPS, occasional corrections and backfills, high availability, low latency, and cost efficiency.

Constraints & Assumptions

  • Historical rates are mostly immutable but can be corrected.
  • Consumers include internal services, analysts, dashboards, and batch data pipelines.
  • Precision, snapshot semantics, auditability, and versioning matter for financial use cases.
  • State assumptions for currencies, pairs, granularity, retention, and latency targets.

Clarifying Questions to Ask Guidance

  • What granularity is required: daily, hourly, minute, tick, or all of these?
  • Do callers need bid, ask, mid, OHLC, or conversion endpoints?
  • What is the required P95 latency and availability SLO?
  • How often do corrections happen and do consumers need as-of historical snapshots?

Part 1 - APIs

Define read endpoints and optional ingestion endpoints.

What This Part Should Cover Guidance

  • Point-in-time rate, time-series rates, conversion, OHLC or aggregate endpoints, and internal ingest.
  • Versioning, pagination, auth, rate limits, idempotency, error handling, precision, and response contracts.
  • REST or gRPC trade-offs for internal callers.

Part 2 - Data Model

Design the entities and fields.

What This Part Should Cover Guidance

  • Currency, currency pair, timestamp, granularity, price type, scaled integer rate, source, version, as-of time, quality flags, and provenance.
  • Indexes and keys for pair and time-range access.
  • Correction handling with immutable versions and audit history.

Part 3 - Storage and Caching

Choose hot storage, cold storage, partitioning, replication, retention, and caching strategy.

What This Part Should Cover Guidance

  • Wide-column, time-series SQL, object storage, Parquet, hot versus cold paths, partitioning by pair and time, and downsampling.
  • In-process, distributed, and precomputed caches; cache keys, TTLs, invalidation, and correction fanout.
  • Cost-efficiency trade-offs.

Part 4 - Consistency, Scalability, and Failure Handling

Explain freshness, snapshot semantics, scaling, multi-region design, and failure modes.

What This Part Should Cover Guidance

  • Strong versus eventual consistency, as-of reads, correction propagation, and backfill behavior.
  • Capacity estimates for 10k QPS, autoscaling, read replicas, multi-region failover, and provider outages.
  • Degraded modes and client guidance.

Part 5 - Monitoring and Operations

Define SLIs, SLOs, alerts, tracing, data quality checks, and runbooks.

What This Part Should Cover Guidance

  • Latency, availability, error rate, cache hit rate, freshness, correction lag, ingestion lag, and data quality metrics.
  • Reconciliation against providers, anomaly detection, missing data alerts, and audit reports.
  • Incident runbooks for stale data, bad corrections, provider outages, and regional failures.

What a Strong Answer Covers Guidance

  • Financial precision and audit semantics.
  • A serving design that handles hot reads and rare corrections.
  • Clear caching and invalidation strategy.
  • Operational controls for correctness, freshness, and reliability.

Follow-up Questions Guidance

  • How would you invalidate caches after a correction?
  • What if two providers disagree?
  • How would you support snapshot-consistent backfills?
  • What is the hot key risk for USD/EUR?
  • Which SLO matters most for analysts versus online services?
Loading comments...

Browse More Questions

More Product / Decision Making•More Google•More Product Manager•Google Product Manager•Google Product / Decision Making•Product Manager Product / Decision Making