Product Event Tracking and Analytics Pipeline With Flexible Schema and Retention
ScribdSoftware Engineer · OnsiteLast updated
This question tests the architectural design of a scalable event-tracking pipeline capable of handling heterogeneous JSON schemas, choosing appropriate storage tiers for analytical queries, and managing data lifecycle policies.
Scenario
You are tasked with building an event-tracking pipeline for a digital content platform. Features across the web and mobile apps emit JSON events containing a fixed header (timestamp, user_id, event_type, source) and a payload object containing feature-specific metadata. The system must support high ingestion rates and facilitate both real-time monitoring and complex analytical queries.
Requirements
- Ingestion: Design an ingestion service that can handle 50k events per second. Explain how to buffer these events before processing.
- Schema Flexibility: Since event types change frequently, describe how to store and query the
payloadfield without forcing a rigid relational schema for every new feature. - Storage Strategy: Choose storage technologies for two use cases:
- Investigative queries: Finding the last 10 actions of a specific
user_id. - Analytical queries: Computing daily active users and feature adoption rates over the last 90 days.
- Investigative queries: Finding the last 10 actions of a specific
- Retention: Outline a strategy to manage costs by moving older data to cheaper storage while keeping it accessible for long-term trend analysis.
Constraints
- The system must ensure low-latency ingestion.
- Analytical queries should not block the ingestion pipeline.
- Data integrity and fault tolerance are required.
Discussion Points
- How do you handle schema evolution (e.g., adding or renaming fields in the JSON payload)?
- How would you implement efficient filtering by
user_idversus aggregated metrics byevent_type? - Describe the trade-offs between using a columnar data warehouse (e.g., BigQuery/ClickHouse) and an operational database (e.g., PostgreSQL/DynamoDB).
Hints
Hint 1
Consider a message broker like Kafka to decouple the ingestion API from the backend processing logic.
Hint 2
Think about using a JSONB column in a relational database for flexibility or a dedicated document store if you need massive horizontal scalability.
Hint 3
Discuss the 'Lambda' or 'Kappa' architecture to handle both the real-time stream processing and the historical batch analytical queries.
Follow-up questions
- How would you handle late-arriving events that are out of order?
- What steps would you take to ensure PII (Personally Identifiable Information) in the event payload is redacted or encrypted?
- If a new event type causes an influx of malformed data, how would you prevent it from crashing your consumer services?
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.