Single broker

One Andromeda broker and one PostgreSQL server. Every entity, every history and every subscription lives in that database, and every request is answered from it. The specification calls this the centralised architecture, with the broker as its Central Broker.

1. ProducersDevices, gateways, services
   ConsumersApplications, dashboards
2. writes in, answers and notifications out
3. AndromedaContext Broker
4. reads and writes
5. PostgreSQLDatabase

Andromeda

When it fits

• The data can live in one place. Most deployments are like this, with one tenant or with many.
• Producers and consumers can all reach one address.
• One team runs it.

Nothing is registered and nothing is forwarded. A request is either answered in full or it fails, apart from the operations that report success entity by entity, such as batches.

What runs

• One andromeda process, serving the API on port 1056.
• One PostgreSQL server. With tenants it holds a database for each, and with many tenants a PgBouncer in front of it helps.

To serve more clients, give the broker and the database more CPU and memory first. Several broker processes on one database are a work in progress and not supported in v1.0.

Sizing, TLS and the proxy in front work as they do in any other deployment, and Choosing a setup goes through them.

Example deployment

This is the file from the Docker page, which explains it line by line. Generate the database password into .env first.

echo "POSTGRES_PASSWORD=$(openssl rand -hex 24)" > .env

docker-compose.yaml

name: andromeda

services:
  postgresql:
    image: ghcr.io/mskvarc/postgresql:18.6-timescaledb2.31.0-postgis3.6.4-tsl
    restart: unless-stopped
    environment:
      POSTGRES_USER: andromeda
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}
      POSTGRES_DB: andromeda
    mem_limit: 4g
    cpus: 2
    volumes:
      - postgresql-data:/var/lib/postgresql

  andromeda:
    image: ghcr.io/mskvarc/andromeda:1.0.0
    restart: unless-stopped
    depends_on:
      postgresql:
        condition: service_healthy
    environment:
      ANDROMEDA__DATABASE__CONNECTION: postgres://andromeda:${POSTGRES_PASSWORD}@postgresql:5432/andromeda
    ports:
      - "1056:1056"

volumes:
  postgresql-data:

Start it with docker compose up -d, then check that it answers.

curl http://localhost:1056/ngsi-ld/v1/version

Growing out of it

Stay on one broker until there is a reason to leave it.

• Data has to stay in a system that already holds it

  Register that system as a context source, and the deployment becomes distributed.

• Another team runs its own broker, and applications should see both

  Put a broker in front of both, and the deployment becomes federated.

Neither move touches the entities already in the broker. Registering a source adds to what the broker answers with and leaves what it holds alone.

If it goes wrong

• Everything stops when the broker or the database restarts

  There is one of each, so a restart interrupts every client. Restart outside the hours that matter. Upgrades describes how the broker drains its requests first.

• The broker answers slowly under load

  The cause is almost always the database. Monitoring lists what to watch, and PostgreSQL shows how to work out connection capacity.