Requirements

Functional Requirements:

• Count views for each video accurately, ensuring every legitimate view is counted, even under high traffic.
• Display real-time or near-real-time view counts to users and content creators.
• Prevent fraudulent or bot views using techniques like watch duration thresholds, rate limiting, IP analysis, CAPTCHA, or device fingerprinting.
• Provide content creators with view count trends broken down by time period (daily, weekly, monthly) for analytics and insights.

Non-Functional Requirements:

• Availability for view count feature, 99.99%, allow 52 min downtime in a year
• Security: able to detect bot, fraudulent views
• Consistency: eventual consistency for view counts

Scalability:

The system must support horizontal scaling to handle high QPS and traffic spikes (e.g., viral videos).

This includes:

• Auto-scaling stateless ingestion services
• Partitioning (e.g., by videoId) to distribute load
• Handling hot keys (popular videos) via sharding or write fan-out strategies

• Hot key: hot videos have higher view counts

Idempotency:

Duplicate events (e.g., retries) must not lead to over-counting.

• View events should be deduplicated based on user/session/time window.

Latency:

• View counts should be visible within sub-second to a few seconds latency (typically <1–3 seconds) to provide a near real-time user experience.

API Design

Video

GET /v1/video/{id}/views

GET /v1/video/{id}

→ Returns current aggregated view count

Report

GET /v1/report/video/{id}/views?start={}&end={}&breakdown=age,device,country&channel=web,app&granularity=[hourly/daily/monthly]

When a user view the video

The frontend batches raw events and sends them periodically using regular HTTP requests.

Additionally, it can use navigator.sendBeacon() to flush any remaining events when the user leaves the page.

POST /v1/events, request: {eventObj}

{

events:[

{event}

]

}

High-Level Design

In this design, I separate the system into an online serving path and an analytics path.

For the online path, user requests go through the API Gateway, which handles routing, rate limiting, and fraud detection. Then the request goes to the view service, which updates or reads the latest view counts from View DB. This path is optimized for low-latency access to current counts.

For the analytics path, I use a separate report service. View events are streamed through Kafka, processed by Flink, and written into Druid through an aggregated pipeline. This supports near-real-time reporting queries. For longer-term analytics such as hourly, daily, or monthly trends, a Batch service writes results into a dedicated report DB.

Finally, I add Redis with a Cache Writer to accelerate common real-time report queries, especially for low-cardinality dimensions. This reduces query latency and protects the analytical backend from repeated hot queries.

To control ingestion latency and throughput, I would tune:

• segment granularity (for example minute-level for fresher queryability),
• Kafka partitioning to scale ingestion in parallel,
• and the number of Druid ingestion tasks / MiddleManager capacity so the system can keep up with traffic spikes.

Detailed Component Design