# Design a Data Service for Downstream Consumers Design a service that exposes governed warehouse or modeled data to reports and applications. It should support stable contracts, access control, pagination or bulk access as appropriate, freshness visibility, and safe evolution when upstream schemas change. ### Constraints & Assumptions - Consumers have different latency and volume needs. - Warehouse queries can be expensive and should not be exposed directly to arbitrary application traffic. - Data may be corrected after initial publication. - Every response must enforce tenant and field-level authorization. - Consumers need a documented freshness contract. ### Clarifying Questions to Ask - Is access request-response, streaming, bulk export, or a combination? - Which entities and query dimensions are supported? - What consistency and freshness bounds are required? - How will breaking contract changes be introduced? ### Part 1 - Contract and serving model Define resources, query limits, schemas, pagination, freshness metadata, and versioning. #### What This Part Should Cover - Purpose-built APIs instead of arbitrary SQL - Stable identifiers and explicit null semantics - Cursor or bulk-export boundaries - Backward-compatible schema evolution ### Part 2 - Data movement and correctness Explain how warehouse changes reach serving storage, how corrections are applied, and how consumers verify completeness. #### What This Part Should Cover - CDC or scheduled materialization - Idempotent versioned updates - Reconciliation and watermarks - Snapshot semantics for large reads ### Part 3 - Reliability and governance Cover caching, rate limits, authorization, audit, observability, and degraded behavior. #### What This Part Should Cover - Least privilege and tenant isolation - Workload quotas and backpressure - Safe stale reads versus explicit unavailability - Lineage and access audit trails ```hint Publish a serving projection A service-owned read model can protect the warehouse from interactive traffic while preserving lineage back to governed facts. ``` ### What a Strong Answer Covers - A bounded, versioned data contract tailored to consumer access patterns - Reliable publication from warehouse truth to serving projections - Snapshot, correction, and freshness semantics - Security, quotas, reconciliation, and actionable observability ### Follow-up Questions 1. How would a client export ten million rows without holding one long database transaction? 2. What should the service return when its serving projection is stale? 3. How would field removal be rolled out without silently breaking consumers?