Skip to main content

Brokers

Esper uses brokers to separate public ingest, policy evaluation, and runtime mitigation delivery.

There are two broker roles:

  • Ingestion broker: Accepts analyzed traffic work from the control plane and stores it for engine processing.
  • Mitigation broker: Accepts mitigation decisions from the engine and makes them available to downstream consumers, inspection paths, and operational housekeeping.

Why brokers exist​

Brokers solve a few different problems at once:

  • They prevent the main control-plane server from flooding the engine directly.
  • They let ingestion, evaluation, and mitigation scale independently.
  • They provide a service boundary for queue inspection, housekeeping, and operational logic.
  • They let Esper use a backing store such as Redis without forcing every other service to know that store's internal keys and queue mechanics.

Runtime shape​

The brokered runtime path is:

raw request -> esper-server -> ingestion broker -> esper engine -> mitigation broker

In a self-hosted deployment, the engine worker is the process that moves items from the ingestion broker into engine evaluation and then publishes the result to the mitigation broker.

Mitigation is intentionally asynchronous in this model:

  • the current request is accepted and enqueued for analysis
  • the engine evaluates it and updates mitigation state afterward
  • later requests for the same tracked actor can be answered using the mitigation broker's active mitigation state

HTTP services backed by private stores​

Esper brokers are thin HTTP services backed by their own private stores.

That means:

  • Other services talk to brokers over HTTP.
  • Brokers own their own queue and cache behavior.
  • Redis is a broker implementation detail, not the integration boundary.

This allows brokers to expose:

  • ingestion and retrieval endpoints
  • queue and item inspection
  • housekeeping operations
  • health endpoints

without forcing the rest of the system to depend on direct Redis access.

Ingestion broker responsibilities​

The ingestion broker is responsible for:

  • accepting brokered ingest requests from esper-server
  • storing and queueing those requests
  • exposing engine-facing claim or retrieval endpoints
  • reporting health for its own connected services

Mitigation broker responsibilities​

The mitigation broker is responsible for:

  • accepting mitigation decisions from the engine
  • storing mitigation decisions for later retrieval
  • storing active mitigation state for tracked actors
  • exposing read and operational endpoints for mitigation state
  • reporting health for its own connected services

Storage ownership​

The brokers do not own engine state.

Engine-owned storage remains separate:

  • Redis for hot entity, session, window, and dedup state
  • PostgreSQL for configuration, symbols, field registry, and durable decisions

The mitigation broker stores mitigation-facing runtime outputs, not the engine's computational state model.

Hosted and self-hosted use​

In hosted deployments, brokers let Esper isolate control-plane traffic from runtime processing.

In self-hosted and on-prem deployments, the same broker model provides the runtime boundary needed for:

  • separate service scaling
  • queue durability and backpressure
  • operational inspection and cleanup
  • explicit service health monitoring

Continue to Esper CLI for the operator commands and local runtime entry points that work with this brokered model.