Design a Data Service for Downstream Consumers
ByteDanceData Engineer · HR ScreenLast updated
Design a centralized, governed data serving platform that provides downstream consumers with stable query APIs, schema evolution safety, cursor-based exports, and data freshness metadata.
Scenario
ByteDance operates numerous core datasets (such as video engagement and creator analytics) that dozens of downstream teams rely on—ranging from real-time recommendation feature stores to batch analytics pipelines. Upstream schema changes frequently break downstream consumers, and direct warehouse access results in resource contention and unpredictable query latency.
Design a multi-tenant Data Access Service that acts as a governed gateway between underlying analytical/operational storage systems and downstream consumer applications.
Requirements
Functional Requirements
- Stable Consumption APIs: Provide flexible read interfaces including single-key projection lookups (e.g., latest creator metrics) and cursor-based batch streaming/pagination for bulk sync.
- Schema Evolution & Versioning: Enforce contract management (e.g., Schema Registry) supporting backward-compatible field additions, deprecations, and projection transforms without breaking downstream callers.
- Data Freshness Evidence: Deliver explicit freshness metadata with every response (e.g., dataset watermark, snapshot timestamp, pipeline lag indicator) to enable downstream reproducibility and validation.
- Governance & Security: Support attribute-based access control (ABAC) and dynamic column-level masking (e.g., PII fields) tailored to consumer credentials.
Non-Functional Requirements
- Low Latency: P99 latency under 30 ms for point/projection lookups.
- High Availability: 99.99% read uptime for the serving layer.
- Scalability: Support 100,000 QPS for point lookups and concurrent multi-gigabyte export streams without impacting primary serving latency.
- Fault Tolerance: Resilient to downstream backpressure and upstream processing delays.
Scale Assumptions
- Core dataset covers 2 billion active entities (e.g., videos, creators).
- 50 TB daily change volume; petabyte-scale cumulative historical data.
- 300+ independent downstream consumer services with differing SLA requirements.
Key Discussion Points
- Architecture & Storage Tiering: Dual-engine storage layout (e.g., distributed key-value / document cache for low-latency point lookups vs. columnar lakehouse/warehouse for batch exports).
- API & Cursor Design: Mechanics of cursor tokens (e.g., stateful vs. stateless encoded cursors with partition and offset metadata).
- Schema Management: How schema validation, projection transformation, and deprecation policies are enforced at the API gateway.
- Metadata & Watermark Propagation: Capturing and serving source pipeline watermarks and snapshot IDs alongside payload data.
Hints
Hint 1
Separate the serving path into an operational cache or key-value store for single-entity projection lookups and an immutable snapshot-based engine for high-volume exports.
Hint 2
Encode dataset snapshot IDs and partition offsets directly into opaque, signed cursor tokens so export requests remain stateless and deterministic across consumer restarts.
Hint 3
Use an API gateway integrated with a central schema registry to dynamically filter, rename, or mask fields according to the consumer's registered contract version and permissions.
Follow-up questions
- How would you handle a downstream consumer that reads so slowly during a bulk export that the underlying storage snapshot risks being garbage collected?
- If an upstream pipeline experiences a 2-hour ingestion delay, how should the data service communicate this degraded freshness to consumers without failing their queries entirely?
- How would you implement zero-downtime migrations when a published field type changes incompatibly (e.g., integer ID to string UUID)?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.