Design ad click aggregator and file sync service
AppleSoftware Engineer · OnsiteLast 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:
- API Design: Key endpoints for both systems.
- Data Model: How data is structured for high-frequency writes (clicks) vs. durable storage (files).
- High-Level Architecture: Core components, communication protocols, and storage choices.
- 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?
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.