Design a Resilient Document Aggregation Service
You are tasked with designing a backend service that assembles a "document bundle" for clients. This process involves calling three independent, existing downstream service APIs to retrieve partial documents (e.g., profile, transactions, statements). Your service must then aggregate these partial documents into a single combined record, persist it to a database, and serve this aggregated record to clients on demand.
Design an end-to-end solution. The downstream APIs are operated by other teams, have varying latency and availability characteristics, and can fail or be slow. Your design must gracefully handle situations where one or more downstream calls fail or time out.
Constraints & Assumptions:
- Three independent downstream document APIs, each with p99 latency in the low hundreds of milliseconds and an availability of approximately 99.5%, with occasional multi-minute outages.
- Aggregation requests arrive at a peak rate of a few hundred per second.
- Client reads of already-aggregated bundles are roughly 10x the write rate.
- Persisted aggregated bundles must be available to clients with read latency in the tens of milliseconds at p99.
- Bundles can tolerate eventual consistency; a client may briefly read a slightly stale bundle, but the system must converge.
- Every aggregation attempt must reach a terminal, observable outcome (succeeded, retried, or parked for investigation), and bundles should not be silently dropped on partial failure.
- The three downstream calls for a given bundle are independent of each other.
Clarifying Questions to Ask:
- Is a bundle valid only when all three sections are present, or can it be persisted as "partial" with missing sections filled in later?
- What is the freshness requirement for bundles on client read?
- Are aggregation requests triggered synchronously by a client request, or asynchronously?
- What is the idempotency key for a bundle, and can the same aggregation be safely re-run without producing duplicates?
- What are the retry/SLA expectations from the downstream teams?
- What are the data-retention and PII/compliance requirements for persisted bundles?
AI interview prep
Core dilemma
Balancing the need for timely and complete document aggregation against the inherent unreliability and latency of independent downstream services, while ensuring data durability and client read performance.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design a Resilient Document Aggregation Service
You are tasked with designing a backend service that assembles a "document bundle" for clients. This process involves calling three independent, existing downstream service APIs to retrieve partial documents (e.g., profile, transactions, statements). Your service must then aggregate these partial documents into a single combined record, persist it to a database, and serve this aggregated record to clients on demand.
Design an end-to-end solution. The downstream APIs are operated by other teams, have varying latency and availability characteristics, and can fail or be slow. Your design must gracefully handle situations where one or more downstream calls fail or time out.
Constraints & Assumptions:
- Three independent downstream document APIs, each with p99 latency in the low hundreds of milliseconds and an availability of approximately 99.5%, with occasional multi-minute outages.
- Aggregation requests arrive at a peak rate of a few hundred per second.
- Client reads of already-aggregated bundles are roughly 10x the write rate.
- Persisted aggregated bundles must be available to clients with read latency in the tens of milliseconds at p99.
- Bundles can tolerate eventual consistency; a client may briefly read a slightly stale bundle, but the system must converge.
- Every aggregation attempt must reach a terminal, observable outcome (succeeded, retried, or parked for investigation), and bundles should not be silently dropped on partial failure.
- The three downstream calls for a given bundle are independent of each other.
Clarifying Questions to Ask:
- Is a bundle valid only when all three sections are present, or can it be persisted as "partial" with missing sections filled in later?
- What is the freshness requirement for bundles on client read?
- Are aggregation requests triggered synchronously by a client request, or asynchronously?
- What is the idempotency key for a bundle, and can the same aggregation be safely re-run without producing duplicates?
- What are the retry/SLA expectations from the downstream teams?
- What are the data-retention and PII/compliance requirements for persisted bundles?