Belay.Notifier behaviour (Belay v2.0.0)

Copy Markdown View Source

Wake-up delivery for low-latency dispatch.

Notifiers are accelerators, never load-bearing: polling remains the correctness floor, so a lost or unavailable notifier costs latency, not jobs. Two ship built-in:

  • Belay.Notifier.Local (always on) — in-process registry pokes plus :pg broadcast when BEAM nodes are clustered with distributed Erlang. Same-node dispatch is effectively instant; clustered dispatch is a message send away.

  • Belay.Notifier.Postgres (opt-in) — pg_notify wake-ups through the database, for fleets that share Postgres but not an Erlang cluster:

    {Belay,
     name: MyApp.Belay,
     storage: [adapter: :postgres, url: url],
     notifiers: [:local, :postgres],
     ...}

    The listening side uses one dedicated connection per node (Postgrex.Notifications, auto-reconnecting) — point listen_url: at a direct connection if your main URL goes through a transaction pooler. NOTIFY payloads here are tiny (a queue name or job id), and if the channel is down you fall back to busy_poll/poll_interval pickup.

Summary

Callbacks

Deliver a wake-up through this notifier.

Optional listener process for the receiving side.

Types

message()

@type message() :: {:poke, String.t()} | {:result, integer()}

Callbacks

broadcast(t, message)

@callback broadcast(Belay.Config.t(), message()) :: :ok

Deliver a wake-up through this notifier.

child_spec(tuple)

(optional)
@callback child_spec({Belay.Config.t(), keyword()}) :: Supervisor.child_spec()

Optional listener process for the receiving side.