name: bid-storm

services:
  postgres:
    image: postgres:16-alpine
    command: >
      postgres -c max_connections=200
               -c shared_buffers=512MB
               -c synchronous_commit=on
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    ports:
      - "${POSTGRES_PORT:-5432}:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 2s
      timeout: 3s
      retries: 20
    # The three strategies are only comparable if CPU and memory are the same
    # for all of them. C1 verifies these with `docker inspect`, not by reading
    # this file: a declared limit that Compose silently ignores is not a limit.
    cpus: 2.0
    mem_limit: 2G
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 2G

  redis:
    image: redis:7-alpine
    ports:
      - "${REDIS_PORT:-6379}:6379"
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 2s
      timeout: 3s
      retries: 20
    # Limited from etapa 2 on, and bench/env.sh records it: the idempotency
    # middleware put Redis in the hot path of the three engines, so it is now
    # part of what the third method invariant fixes. One CPU because Redis
    # executes commands on a single thread anyway, and 512M against entries of a
    # couple hundred bytes that expire in five minutes.
    cpus: 1.0
    mem_limit: 512M
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M

  # Runs to completion before auctiond starts. No Go dependency on
  # golang-migrate: auctiond only has to *read* schema_migrations.
  migrate:
    image: migrate/migrate:v4.18.2
    volumes:
      - ./migrations:/migrations:ro
    command:
      - -path=/migrations
      - -database=postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}?sslmode=disable
      - up
    depends_on:
      postgres:
        condition: service_healthy
    restart: "no"

  # Inside the compose, never on the host: a process under benchmark that runs
  # on the host has no resource limit at all.
  auctiond:
    build:
      context: .
    environment:
      DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}?sslmode=disable
      REDIS_URL: redis://redis:6379/0
      HTTP_ADDR: ":8080"
      DB_POOL_SIZE: ${DB_POOL_SIZE:-25}
      BID_STRATEGY: ${STRATEGY:-optimistic}
    ports:
      - "${HTTP_PORT:-8080}:8080"
    depends_on:
      migrate:
        condition: service_completed_successfully
      redis:
        condition: service_healthy
    cpus: 2.0
    mem_limit: 1G
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 1G

  # The second long-lived process of the project, and the one the chaos scenario
  # of spec 02 kills. No `profiles`: a closerd that only came up in some runs
  # would make two cells of the same matrix measure different systems, and it
  # costs almost nothing with nothing to close — it sits blocked on XREADGROUP.
  # Half a CPU and 256M because it is a sequential consumer doing one UPDATE at a
  # time; the limit is there so it cannot compete with auctiond in a spike, not
  # because it needs the ceiling (decisão 80). bench/env.sh records both.
  closerd:
    build:
      context: .
    entrypoint: /usr/local/bin/closerd
    environment:
      DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}?sslmode=disable
      REDIS_URL: redis://redis:6379/0
    ports:
      - "${CLOSERD_PORT:-8081}:8081"
    depends_on:
      migrate:
        condition: service_completed_successfully
      redis:
        condition: service_healthy
    cpus: 0.5
    mem_limit: 256M
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 256M

  # Never on the host, for the same reason auctiond is not: a load generator
  # without a resource limit has no limit at all, and when it saturates the
  # queue forms in the client while the client's clock is already running — the
  # effect arrives looking like server latency. Under `profiles: [bench]` so
  # `make up` never starts it, and speaking to auctiond over the compose network
  # so the host port-forward is out of the hot path.
  k6:
    image: grafana/k6:0.55.0
    profiles: [bench]
    volumes:
      - ./bench:/bench
    environment:
      BASE_URL: http://auctiond:8080
    cpus: 2.0
    mem_limit: 1G
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 1G

  prometheus:
    image: prom/prometheus:v2.55.1
    volumes:
      - ./deploy/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
    ports:
      - "${PROMETHEUS_PORT:-9090}:9090"

  grafana:
    image: grafana/grafana:11.3.0
    environment:
      GF_SECURITY_ADMIN_USER: ${GRAFANA_USER}
      GF_SECURITY_ADMIN_PASSWORD: ${GRAFANA_PASSWORD}
      GF_USERS_ALLOW_SIGN_UP: "false"
    volumes:
      - ./deploy/grafana/provisioning:/etc/grafana/provisioning:ro
    ports:
      - "${GRAFANA_PORT:-3000}:3000"
    depends_on:
      - prometheus

volumes:
  pgdata: