How would you design a near real-time social proof notification system?

WHAT THIS TESTS: Whether you understand stream processing and distributed data processing well enough to turn high-frequency write events into low-latency reads without creating hot spots or database overload. Interviewers want to see that you distinguish between exact consistency and good-enough accuracy for a growth feature.

A GOOD ANSWER COVERS: Four layers in order. First, ingestion via a lightweight fire-and-forget beacon from the client so the critical path is not blocked. Second, a message bus or stream management system like Kafka or Kinesis to absorb traffic spikes and decouple producers from consumers. Third, a stream processor using windowed aggregation to count unique viewers per item over a rolling interval, which naturally handles parallel processing for data streams. Fourth, a hot cache with a short TTL that the client polls or receives via push, keeping reads away from the database. The candidate should explicitly discuss the trade-off: exact counts require expensive coordination, so approximate counts or fixed windows reduce system load by orders of magnitude while still feeling real-time to users.

COMMON WRONG ANSWERS: Proposing a synchronous SQL update on every page view, which turns the item row into a hot key and collapses under concurrent load. Suggesting exact deduplication per user per second without explaining the storage cost. Ignoring cache invalidation and serving stale counts indefinitely. Proposing WebSocket connections for all users to push updates, which scales poorly for a simple read-only notification.

LIKELY FOLLOW-UPS: How would you handle bot traffic skewing the count? How do you aggregate across multiple data centers? What happens when an item goes viral and the cache hit rate drops? How would you A/B test whether the notification actually increases conversion?

ONE CONCRETE EXAMPLE: Imagine an e-commerce site with one million concurrent users. Each product page emits a beacon to a Kafka topic. A Flink job consumes the topic, maintains a five-minute tumbling window per product ID, and writes the resulting count to Redis with a ten-second TTL. The web frontend reads Redis every fifteen seconds. The count may lag by ten seconds and could include duplicate sessions, but the system handles millions of events per second on modest hardware because the stream processor traces parallel processing and the cache shields the database.