Katkat

Design ad click aggregator and file sync service

AppleSoftware Engineer · Onsite

Last updated

This question tests the ability to design a high-throughput event processing system for ad clicks and a scalable file synchronization service, focusing on data consistency, idempotency, and distributed storage patterns.

Part 1: Ad Click Aggregator

Design a system that tracks and aggregates ad clicks for a platform serving millions of requests per second. Each click event includes click_id, ad_id, user_id, and timestamp.

  • Requirements: Provide accurate real-time aggregates (clicks per ad per minute). Ensure idempotency so that network retries do not count the same click multiple times. Handle events that arrive slightly out of order due to network latency.
  • Scale: 100,000+ clicks per second.

Part 2: File Sync Service

Design a service similar to Dropbox that allows users to store files and sync them across multiple devices.

  • Requirements: Support uploading, downloading, and synchronization of file updates. Implement conflict resolution when two devices edit the same file simultaneously. Provide a mechanism for versioning.
  • Scale: 10 million active users; handle efficient updates for large files (e.g., delta-syncing).

Your Answer Should Cover:

  1. API Design: Key endpoints for both systems.
  2. Data Model: How data is structured for high-frequency writes (clicks) vs. durable storage (files).
  3. High-Level Architecture: Core components, communication protocols, and storage choices.
  4. Trade-offs: Discuss consistency vs. availability for the click aggregator, and latency vs. bandwidth usage for the sync service.

Hints

Hint 1

For the click aggregator, consider using a distributed message queue to decouple ingestion from processing and a windowing strategy for aggregation.

Hint 2

For the file sync service, use a 'chunking' strategy where files are broken into smaller blocks to minimize the amount of data transferred when only a portion of a file changes.

Hint 3

For idempotency in clicks, use a persistent key-value store or Bloom filter to track processed click IDs within a sliding time window.

Follow-up questions

  • How would you handle the case where a user is offline for several days and reconnects to sync thousands of accumulated changes?
  • If the click aggregator requires strictly accurate totals, how would you change your architecture compared to a system that tolerates minor discrepancies for better performance?
  • How would you implement file sharing between users while maintaining granular access control lists?