Operate / PRODUCT GUIDE

Architecture and reliability

Understand what is durable, what is asynchronous, and what recovery can and cannot guarantee.

Reviewed 2026-11-15Print-friendly guide

The event path#

Diagram of the AckNexa components. Monitoring sources (Prometheus Alertmanager, Icinga, Alerta, generic webhooks and heartbeat pings) send authenticated HTTPS requests to the API, which contains the integration gateway. The API commits each raw event and its outbox row to PostgreSQL, the system of record, in one transaction. Workers publish committed outbox events to NATS JetStream and consume them to normalize, deduplicate and route alerts. Workers also run escalation, notifications, status pages, stakeholder updates, chat channels, outbound webhooks, ticketing, audit streaming, heartbeats, postmortems, retention and reconciliation. They deliver through SMTP email, APNs, FCM or the push relay, Twilio SMS and voice, a voice bridge to your PBX, Slack, Teams and Mattermost, signed webhooks, Jira and Halo, and a SIEM. Responders are paged and act in the Web UI or the iOS and Android apps, which talk to the API. An identity provider (OIDC, LDAP, SCIM) and the CUCM gateway for live call routing are optional and connect to the API.
AckNexa components and the systems they connect to. Dark boxes are AckNexa components, light boxes are your systems or providers, and dashed boxes are optional. Open the full-size diagram.
  1. A monitoring source sends an authenticated event to the integration gateway in the API.
  2. PostgreSQL commits the raw payload and outbox event together before the API returns accepted.
  3. An outbox publisher sends committed work to NATS JetStream; a consumer normalizes, routes and deduplicates it.
  4. Incident state and escalation jobs are persisted in PostgreSQL.
  5. Workers claim due escalation jobs and create notification work; provider attempts and results are tracked separately.
  6. Responders view the same authoritative state through the Web/API and acknowledge or resolve the incident.

What each dependency owns#

ComponentResponsibility
PostgreSQLAuthoritative configuration, raw events, incidents, jobs, notification history and audit.
NATS JetStreamDurable transport for asynchronous committed work; not a replacement for the database.
RedisAvailable in the on-prem profile; no current core correctness dependency.
Web/APIAuthenticated interaction, ingress validation and authoritative state changes.
WorkersProcessing, escalation, notification dispatch and reconciliation.

Concurrency and ordering#

State transitions lock the incident and validate the requested version. Jobs and notification attempts use leases and durable state to support restart/recovery. Source timestamps prevent older alert state from replacing newer observations. Delivery is at least once with database idempotency; this is not a blanket exactly-once delivery promise.

When infrastructure fails#

  • Database unavailable: state changes cannot safely commit; readiness fails and clients should retry appropriately.
  • NATS unavailable: accepted outbox records remain in PostgreSQL. Broker supervision is separate from SQL workers; reconciliation can recover aged unprocessed raw events.
  • Worker restart: pending work remains durable or leases expire for recovery.
  • Provider outage: affected notification attempts fail/retry visibly; incident access and response remain available if core dependencies are healthy.
  • Whole stream lost: published outbox records are not automatically all replayed. Restore/replay must be coordinated and tested.

Capacity and deployment evidence#

Find your next step.

Search runs locally. Nothing is sent to a search service.