Functional Requirements (what the system must do)

1. Track ad clicks in real time — when a user on a website clicks an ad, record the event with ad_id, user_id (cookie), timestamp, and click metadata (IP, browser, referrer).
2. Aggregate clicks by time window — produce click counts per ad over windows like minute/hour/day. This powers the dashboards advertisers see.
3. Support demographic & contextual breakdowns — slice the data by age, gender, geo location, and the website where the ad appeared, so advertisers can see who clicked and where.

Non-Functional Requirements (how it behaves)

1. Real-time / low latency — advertisers make live budget decisions, so click counts must update in seconds, not hours.
2. Scalability — handle millions of clicks per day (or hour) across many ad placements — needs horizontal scaling.
3. Eventual consistency is acceptable — losing a click or showing a slightly stale count for a few seconds is fine; ACID transactions aren't needed. Availability matters more than strict consistency.

A good framing for the interview: high write throughput + near-real-time reads + a handful of aggregation dimensions is what drives most of your later design decisions.

Want to paste that into the Requirements panel and I'll review it, or would you like to go deeper on one of these (e.g., why eventual consistency is the right call here)?

Capacity Estimation

1 Event -> 50 bytes

100K request -> 50 MB

1 Invocation can handle 100 request/second -> 1000 Invocations

1 month of retention -> 260tb storage

API Design

POST - Generate Events

/api/v1/event

• Request body: {timestamp:xxx, hostname: xxx, matadata: {age: 18, gender: male, geolocation: japan}}
• Response: 201 Success

GET - Get statistics by time/url

/api/v1/stats/querystring=

• Request: url=xxx&&timestamp=xxx
• Response body: {timewindow: xxx - xxx, click_rate: 30%, total_clicks: 100}

High-Level Design

Main Components:

• API Gateway: Serves as a entry point for all the request. For the first time login, users need to authenticate through the auth server.
• Message Queue: When an event is received, it will be queued here and wait for processor to digest the message. Kafka is preferred in this case.
• Processor: The processor will fetch the data from the queue and store into Time-Series database. Serverless is preferred for scaling easily.
• Storage: Use time-series db like influx, it can quickly fetch the window by time-based index.
• Statistic Application Server: backend server to serve the data by API. Additional cache layer is used to serve frequently ask data.
• Monitoring: monitor stacks to check the states of each services.

Resilience

• When the POST request failed, it retries with exponential backoff
• When the server goes down, the monitoring stacks will trigger the alert and restart the server

Scaling

• Based on the request count metrics, it scale up the invocation counts

Security

• All requests must be authenticated through the Auth Server
• Sync proxy is enabled on the API server

Data Flow:

1. When a click is triggered, the front-end sends a post request to record the event(user, host, time).
2. The message is stored into the queue, and the processor will fetch, proceed then store into the DB.
3. Advertiser can query the data through the APIs exposed from statistic application server.

Technology Stack:

Database Design

Timestamp

_id: unique event ID

hostname

metadata(age/gender/geolocation)

Detailed Component Design

1. Processors: Processor will consume the data sent to the queue(Kafka), and doing validation before ingesting into the DB.
2. Statistic Application Server: When receive a query it checks Cache(Redis) to see if exists. If not, query the time-series db.