• User devices have a persistent connection to the Realtime Platform servers.
• The servers use server-sent events to stream data fast on this connection via the EventSource interface.

A persistent connection is an HTTP Long Poll i.e. a regular HTTP connection where the server doesn't disconnect it.

• Each connection is managed by an Akka actor.
• Actors are so lightweight that there can be millions of them on a single system. Moreover, all of them can be served by a small number of threads, proportional to the number of cores. This is possible because a thread is assigned to an actor only when it has work to do.
• Actors are managed by an Akka supervisor actor that sends them events (likes, comments etc.) which need to be forwarded to user devices.

Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven apps.

• Clients are subscribing to events for a particular live video i.e. they are telling the server which live video they are watching.
• The Frontend server stores all subscriptions in an in-memory table.
• Every time a new event is published, the supervisor actor does a lookup in the in-memory table to determine which actors need to receive this event.

• Scale horizontally to handle more concurrent viewers -> Add multiple Frontend nodes and coordinate them using a Dispatcher node.
• In a similar fashion to the Frontend node, the Dispatcher has a subscriptions table to know which frontend nodes should receive which events.
• This table is populated when Frontend nodes send subscription requests to tell the Dispatcher which live videos they're interested in (i.e. which live videos its connections are subscribed to).

• Scale horizontally again to handle more events -> Add multiple Dispatchers and move the subscription table into a key-value store so it's accessible to all Dispatchers.
• Dispatchers are independent from Frontend nodes and don't have persistent connections between them.
• Any Frontend node can subscribe to any Dispatcher.
• Any Dispatcher can publish events to any Frontend node.

1. A viewer likes a video and sends an HTTP request to the Likes backend, which stores it in a database.
2. The backend forwards the like to any random Dispatcher node using an HTTP request.
3. Dispatcher looks up in the key-value store to find out which Frontend nodes are subscribed to likes from that video.
4. Dispatcher sends the like to the corresponding Frontend nodes.
5. Frontend nodes send the like to client devices which are subscribed to that video.

Expanding to other regions requires two steps:

1. Replicate the setup in each data-center.
2. Have the Dispatcher broadcast the events to its peer Dispatchers from the other data-centers.

• Each Frontend node handles 100k persistent connections. It handles only this many connections because the server is doing a lot of work processing multiple types of data (likes, comments, instant messaging etc.).
• Each Dispatcher can publish 5k events per second to the Frontend nodes.
• End-to-end Publish Latency is 75ms at p90, from the moment the Like is received until the Like is sent to a viewer. There are only two lookups in the subscriptions tables and a series of network calls.
• The system is completely horizontally scalable. You can add more Dispatchers and Frontend nodes to handle more viewers and more events.

• How LinkedIn displays Presence indicators in real-time: https://engineering.linkedin.com/blog/2018/01/now-you-see-me--now-you-dont--linkedins-real-time-presence-platf
• How LinkedIn measures end-to-end latency across systems: https://engineering.linkedin.com/blog/2018/04/samza-aeon--latency-insights-for-asynchronous-one-way-flows
• How LinkedIn scaled one server to handle hundreds of thousands of persistent connections: https://engineering.linkedin.com/blog/2016/10/instant-messaging-at-linkedin--scaling-to-hundreds-of-thousands-