Designing a scalable live interactive polling system (Slido)

This article explores the system design needed to create a tool like Slido, an interactive platform for live polls. Slido allows users to join event rooms and respond to questions in real-time, with all responses being aggregated live for instant feedback.

source— https://www.slido.com/features-live-polling

System Design

This architecture displays the overall working without diving into authentication part, as that can be done via a stateless JWT based auth method for admin and users part.

The major focus is on scalability

1. Output UI (#event1, #event2, #eventN):
   • These are the user interfaces that connect to the WebSocket servers and listen for real-time events associated with specific event IDs, also accumulates the events on the client side.
   • JWT based authentication
2. WebSocket Gateway Cluster:
   • This consists of multiple stateful WebSocket servers (1, 2.. N).
   • Each WebSocket server accepts events based on the event IDs for their connected clients and discards other using an internal hashmap lookup.
   • Uses async kafka consumer to accept the broadcast events.
   • This is scalable as any output UI can be connected to any websocket server, and since we are getting every user event the server needs to just accept the events for connected #eventid.
3. Kafka:
   • Kafka acts as the message broker, receiving user actions from the API Gateway and broadcasting the events to the WebSocket Gateway as well as event processor api to store in redis.
   • Has 1 Topic to accept user events with multiple partitions to handle scalability, this is subscribed via eventprocessor and websocket servers.
4. API Gateway (Stateless):
   • This receives POST requests from the User UI and forwards the data to Kafka with the associated event ID.
   • JWT based authentication
5. Redis:
   • Redis stores event data and is accessed by the Event Processor.
   • It plays a role in refreshing or loading data during startup.
   • This is also a cluster based redis so not a SPOF.
6. Event Processor:
   • It accumulates the data in redis.
   • The Event Processor is responsible for refreshing or loading data from Redis and broadcasting the necessary updates.
   • uses kafka sync commit to gaurantee atLeast once delivery of events.

Thanks for reading, please share your views or any suggestions.