My high level understanding of realtime architecture

There are a few layers involved in making a realtime app. Internally your infrastructure will need to be able to support reacting to updates instantly. That’s pretty difficult to do when you have multiple servers and clients making updates while also asking to be notified of those changes in realtime.

RethinkDB handles that at the db level. Meaning your web servers can directly ask the database when an update has occurred. Most other databases don’t have a way for servers to open a communication channel that allows them to be notified of database changes as they occur. In relational databases you might accomplish this with table triggers or if you use Postgres, the notify command.

RethinkDB makes it easy to subscribe to database changes, and has a cool query language. However in a lot of cases in realtime apps your clients will disconnect and reconnect and will require knowledge of the change log of updates since the last time it was connected. To do that you’d need to have knowledge of which updates were sent to which clients. For functionality that relies on that feature you’d likely need a dedicated message queue like RabbitMQ or AWS’s hosted SQS or Kinesis service. RethinkDB at the time of writing this doesn’t support transactions either, which are pretty important for a lot of apps.

With a message queue, your servers would push a message to a channel after a successful database update. That way all servers can respond to updates as they occur on other servers. This is important for the Websocket layer. Websockets are how the browsers can react to realtime changes. Millions of browsers will open persistent TCP connections, potentially spread out across multiple web servers to send and receive notifications of updates and other events.

The websocket layer is a bit more complex than your average REST API. The RethinkDB team built Horizon to do make that easier (basically a self hosted Firebase). Scaling websocket servers is also more complicated than your average REST api. That’s why services like Firebase and PubNub exist, they handle that complexity for you.

Firebase is a full service database, message queue and static hosting solution that pretty much acts as 90% of your backend. It makes building MVPs really fast but there are natural tradeoffs when you have a system takes over a large portion of your infrastructure.

PubNub acts as that scalable WebSocket / Message Queue layer which is a nice middle ground. They have a feature called BLOCKS which also looks interesting since you can provide it javascript code that runs in the server much like AWS Lambda but for WebSockets.