Design a System for Live Stream Polling/Reactions

To design a scalable live polling system, I would start by defining non-functional requirements: we need sub-200ms end-to-end latency and support for millions of writes per second during viral moments. For ingestion, clients would send reaction requests to a global load balancer, which routes traffic to edge nodes running our proprietary caching layer. These edge nodes aggregate local counts before pushing batches to a distributed message broker like Kafka. This decouples ingestion from processing, allowing us to absorb massive write spikes without crashing the database. For real-time display, we'd use a pub/sub model where aggregated updates are pushed via WebSockets to connected clients. To handle durability, we'd asynchronously persist these aggregates to a wide-column store like Cassandra, partitioned by StreamID to ensure isolation. If a specific stream goes viral, we can dynamically add more partitions. We must also consider rate limiting at the edge to prevent abuse. Finally, for polls, since votes are often one-time actions, we can treat them as high-priority writes to ensure they appear instantly. This architecture balances the need for immediate feedback with the durability required for post-stream analytics.