Design an ad click tracking system
MetaSoftware Engineer · OnsiteLast updated
This problem tests your ability to design a high-scale, fault-tolerant distributed system capable of processing massive volumes of real-time ad click events while ensuring data consistency and accuracy.
Scenario
You are tasked with designing a backend system for an ad platform that records clicks on advertisements. The system must handle millions of events per second with sub-second latency for recording, while providing an eventually consistent view of click counts for billing and analytics.
Requirements
- Functional:
- Ingest click events:
(click_id, user_id, ad_id, timestamp, device_info). - Support querying click counts by
ad_idover various time windows. - Ensure deduplication: A single user clicking the same ad multiple times within a 30-second window should only count as one unique click.
- Ingest click events:
- Non-Functional:
- High availability: The system should not drop events during traffic spikes.
- Scalability: Must handle 10 million clicks per second during peak hours.
- Consistency: Billing must be accurate; data loss is unacceptable.
Expectations
Your design should cover:
- High-level Architecture: API gateways, message queues, and processing services.
- Data Modeling: Storage schema for raw events vs. aggregated metrics.
- Scaling Strategy: How to partition and shard data to prevent hotspots (e.g., viral ads).
- Reliability: Handling downstream service failures and ensuring exactly-once processing semantics where possible.
- Trade-offs: Justify your choice of storage engines (e.g., NoSQL vs. Time-series databases) and processing patterns (stream vs. batch).
Hints
Hint 1
Consider using a distributed message broker like Kafka to decouple ingestion from processing and provide a buffer during traffic spikes.
Hint 2
To handle deduplication at scale, use a sliding window approach with a distributed cache like Redis or a Bloom filter to track recent clicks per user-ad pair.
Hint 3
For long-term storage and analytical queries, think about an OLAP database or a data lake solution like BigQuery or Druid that supports efficient time-based aggregation.
Follow-up questions
- How would you modify your design if you needed to support real-time fraud detection, such as identifying click farms?
- If the system experiences a massive backfill of late-arriving events, how would you ensure the reporting dashboard remains performant and accurate?
- How would you transition from a 'count-based' billing model to a 'cost-per-acquisition' model, which requires joining clicks with conversion events?
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.