architecture

10 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Realtime is a globally distributed Elixir cluster

Realtime is written in Elixir, which compiles to Erlang, and uses many tools the Phoenix Framework provides. Clients can connect to any node in the cluster via WebSockets and send messages to any other client connected to the cluster.

Phoenix Framework handles millions of concurrent connections

Phoenix is fast and able to handle millions of concurrent connections. Phoenix can handle many concurrent connections because Elixir provides lightweight processes (not OS processes) to work with.

Realtime region failover with multiple nodes

Every Realtime region has at least two nodes so if one node goes offline the other node should reconnect and start streaming changes again.

Realtime database connection types

Realtime uses several database connections: Migrations (two temporary connections to run database migrations when needed), Authorization (configurable connection pool to check authorization policies on join, always started), Broadcast from database (one connection to receive data from replication slot used to broadcast changes to clients, always started), and Postgres Changes (multiple connection pools for subscription management, subscription cleanup, and WAL pull, only started if Postgres Changes is used).

Default connection pool sizes by compute add-on

Default database connection pool sizes for Realtime vary by compute add-on: Nano and Micro have 1 broadcast connection, 2 authorization pool, 2 subscription management, 2 subscription cleanup, 2 WAL pull; Small, Medium, and Large have 1 broadcast, 5 authorization, 4 subscription management, 4 subscription cleanup, 4 WAL pull; XL and 2XL have 1 broadcast, 10 authorization, 7 subscription management, 7 subscription cleanup, 7 WAL pull; 4XL and 8XL have 1 broadcast, 10 authorization, 7 subscription management, 7 subscription cleanup, 7 WAL pull; 12XL and 16XL have 1 broadcast, 15 authorization, 9 subscription management, 9 subscription cleanup, 9 WAL pull; >16XL has 1 broadcast, 15 authorization, 9 subscription management, 9 subscription cleanup, 9 WAL pull.

Authorization Pool Size is configurable

The Authorization Pool Size can be customized through the Database connection pool size parameter in Realtime configuration. If not specified, default values shown in the table will be used.

Realtime uses maximum 2 replication slots

Realtime uses at maximum 2 replication slots: one for Broadcast from database to broadcast changes from the database to clients, and one for Postgres Changes to listen to changes from the database.

Realtime schema tables

The realtime schema creates the following tables: schema_migrations (to track migrations run on the database from Realtime), subscription (to track subscribers to Postgres Changes), and messages (a partitioned table per day used for Authorization and Broadcast from database).

realtime.messages table schema

The realtime.messages table has the following columns: topic (text, not null) - the topic of the message, extension (text, not null) - the extension of the message (presence, broadcast), payload (jsonb, nullable) - the payload of the message, event (text, nullable) - the event of the message, private (boolean, default false) - if the message uses a private channel, updated_at (timestamp without time zone, not null, default now()) - the timestamp when the message was updated, inserted_at (timestamp without time zone, not null, default now()) - the timestamp when the message was inserted, id (uuid, not null, default gen_random_uuid()) - the id of the message. The table is partitioned by RANGE (inserted_at) with a primary key constraint on (id, inserted_at).

Realtime cleanup process for messages

Realtime has a cleanup process that will delete message tables older than 3 days.

Give your agent this brain