1. Home
  2. Docs
  3. Architecture & scale
  4. Dashboard, outbox and snapshot architect...
Architecture & scale

Dashboard, outbox and snapshot architecture

How OneTALA keeps operational writes authoritative while building faster campaign decision views.

Developer v2026.10 Updated 4 Nov 2026

Source of truth

Operational campaign tables in PostgreSQL remain authoritative. Dashboard acceleration must never become a second write authority.

Go campaign projection

go-dashboard consumes the durable analytics_outbox_events stream and coalesces changes by tenant and campaign. It builds versioned Campaign projections for overview, SPAQ, referral and CDD views. The checkpoint advances only after affected projections succeed, providing at-least-once processing.

Redis is the fast decision layer for compatible unfiltered projections. Laravel validates schema/version and scope before using a fast snapshot and falls back to its own cached PostgreSQL query when a projection is missing, stale or unsupported.

Published PostgreSQL snapshots

The codebase also contains published dashboard snapshot/read-model support. Snapshot rows are built, marked ready, atomically published through a snapshot head, and then read using a pinned snapshot ID/cut-off time. This prevents users from seeing a partially rebuilt dashboard.

Geographic and filtered views

Filtered state/LGA/ward/HF/DP views remain scope-aware. A user must never receive data outside their authorized geography merely because a broad cache already exists.

Was this page helpful?

Still stuck?

Open a ticket and reference this page — we will pick it up from there.

Open a ticket