How it works
- Events commit.
- EventDBX enqueues a job per enabled plugin (respecting its payload mode and
emit_eventsflag). - A short-lived delivery is attempted; failures stay in the queue and retry with backoff until
plugin_max_attempts.
Explicit publish (opt-in)
You can override the default “fan out to all enabled plugins” on a per-write basis. Provide publish targets on the write command to select plugins, override payload mode, and set queue priority:--publish entry is PLUGIN[:MODE[:PRIORITY]]:
PLUGIN– configured plugin name (must be enabled).MODE(optional) – overrides payload shape for this write (all,event-only,state-only,schema-only,event-and-schema,extensions-only); defaults to the plugin’s configured mode.PRIORITY(optional) –low|normal|highfor queue ordering; defaults tonormal.
Configure plugins
Usedbx plugin config <type> to create or update an instance (saved at the system data root, e.g. ~/.eventdbx/plugins.json):
Payload modes
all(default): event + state + schema.event-only: event document only.state-only: latest state only.schema-only: aggregate schema only.event-and-schema: event + schema, no state.extensions-only: identifiers + namespaced extensions; payload/state nulled out.
Retries and backpressure
- Jobs retry automatically up to
plugin_max_attempts(set viadbx config --plugin-max-attempts <n>). - When the persistent queue is unavailable, EventDBX attempts direct delivery and logs failures.
- Use
dbx queueto inspect pending and dead jobs;dbx queue retryreplays failures.
Deployment options
- TCP/HTTP/Capnp/Log plugins run as lightweight emitters inside the server/CLI process.
- Process plugins run as supervised binaries; EventDBX starts/stops them and writes status files under the domain data directory.