Design a system that ingests a firehose of lightweight events (clicks, views) and maintains aggregate counts, absorbing write bursts without losing events or overwhelming the datastore.
Design an analytics ingestion and counting system. Clients emit a high-volume firehose of small events : page views, clicks, impressions : and the system must count them (per key: per-page, per-campaign, etc.) and make aggregates queryable. The defining characteristic is write volume: events arrive far faster and more burstily than any database can accept synchronously, and traffic spikes (a viral event, a campaign launch) can multiply the rate several-fold within seconds.
Writing each event directly to the database on the request path would collapse under load and couple ingest availability to database availability. Instead, ingest must accept events quickly, buffer them through a queue that absorbs bursts, and let downstream consumers aggregate and persist counts asynchronously. The read path (querying aggregates) is comparatively light and served from precomputed counts.
Design the architecture with emphasis on decoupling ingest from persistence via a durable buffer, scaling the ingest tier for burst, and aggregating asynchronously. Then show your capacity math, the trade-offs of the async model (latency-to-visibility, at-least-once vs exactly-once counting), and how you plan capacity for spikes.