Replicas

Running several identical broker processes against the same PostgreSQL database is a work in progress, and it isn't supported or tested in v1.0.

Don't start a second broker on the same database

Run one broker process per database, and size it for your load.

Where it is going

The aim is identical broker processes behind a load balancer, all on one database. That would add capacity, and keep the API answering while one process restarts or fails. This page will describe the setup once it is tested.

Keeping one process available

Until then, availability comes from restarting the one process quickly and from a database that survives its own failures.

• A restart policy

  Let the container runtime or orchestrator restart the broker when it exits, as --restart unless-stopped does in Docker.

• Health checks on the management port

  /livez answers 200 while the process is up, and /readyz answers 503 once a health indicator is down. Monitoring explains what each one checks.

• A database that comes back

  While PostgreSQL restarts or fails over, the broker answers the requests that need it with 503 and Retry-After: 5, and picks up again by itself once the database is back. Store outages describes what clients see.

• Room to grow on one process

  Size the pools and the server to the load, as Connection capacity describes. With many tenants, PgBouncer lets one process keep hundreds of them loaded.