Katkat

Design an ad click tracking system

MetaSoftware Engineer · Onsite

Last 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_id over 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.
  • 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:

  1. High-level Architecture: API gateways, message queues, and processing services.
  2. Data Modeling: Storage schema for raw events vs. aggregated metrics.
  3. Scaling Strategy: How to partition and shard data to prevent hotspots (e.g., viral ads).
  4. Reliability: Handling downstream service failures and ensuring exactly-once processing semantics where possible.
  5. 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?