Figure 1. is an example layout where 3 agents, 1 brainz and 1 API-GW instances are used. There is no theoretical limit on the number of instances when it comes to Brainz, Agent and API-GW. Routers can also be scaled with multiple instances, they will all use the same configuration.
Brainz, Agent, Router and API-GW talk over NATS. The agent talks to varnishadm to manage VCLs,
etc. Brainz instances have connections toward the PostgreSQL database and are the only type of
process that performs database operations in the system. The API-GW talks HTTP for the REST API and
requests toward any of the API-GW instances are possible. A load balancer could be used in front of
the API-GWs.
The Routers also uses HTTP for Health Checks towards Varnish servers.
The optional UI server serves the web UI and proxies its API requests to the API-GWs over HTTP. It can also connect to NATS, which is how it receives its configuration, TLS certificates and ACME challenges from Brainz, and how single sign-on reaches Brainz. Several UI servers can be run behind a load balancer. They share one global configuration rather than being registered individually.
There is a 1-to-1 relationship between an agent and a Varnish instance. Hence, one agent can only handle one Varnish instance.
A client (Internet user) can either have a router as a first point of contact, which will forward the client to the most suitable Varnish server. Or the client can access the Varnish servers directly. Using the Varnish traffic router with Varnish Controller is optional.
