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: User experience degradation: users cannot see up-to-date view counts, which reduces trust in the platform, especially for popular or trending content.
• 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

Hot video: The real hot-key mitigation should happen in the counting pipeline by sharding very hot videos into multiple logical subkeys, for example (videoId, shardId), where shardId may be derived from a user or session hash.

If a view count is not found in the cache, I would fall back to the serving source of truth instead of recomputing from raw events.

• For the current/latest view count, the service reads from the View DB or real-time aggregated store.
• For real-time analytics or recent trends, it can query Druid.
• For hourly/daily/weekly/monthly reports, it falls back to the report DB.

Deduplication and idempotency are related but separate concerns.

They should rely on a stable event identity, such as an eventId or a deterministic composite key, so retries or replayed events do not cause double counting.

For real-time view count aggregation, events can be partitioned by videoId or (videoId, shardId) in Kafka.

Each partition is owned by only one consumer instance in the consumer group.

This ensures all events for the same aggregation key are handled sequentially by the same consumer, which avoids concurrent updates to the same partial counter.