Aller au contenu principal

Event Sourcing

Use this page when you need to understand the canonical write-truth behind Helpifyr flows before you reason about projections, automation, or recovery behavior.

When to use this page​

  • You need to know why events are treated as append-only truth rather than mutable workflow state.
  • You are deciding whether replay, rebuild, or idempotent recovery is safe.
  • You need the public-safe explanation of the Fabric event spine before reading route-level event modeling details.

Prerequisites​

Architecture / Flow​

Step-by-step procedure​

1. Start from append-only event truth​

In Helpifyr, cross-system event truth is owned by Fabric and written as append-only history.

That means:

  • the canonical record is the event log, not a mutable summary page
  • ordering and replay posture matter
  • downstream state is derived, not source truth

2. Treat projections as rebuildable derived state​

Operator-friendly summaries, readiness views, and catalogs are useful, but they are not the canonical write path.

Use event sourcing thinking whenever you need to separate:

  • source truth
  • derived projection
  • replay preview
  • recovery action

3. Keep replay and idempotency explicit​

Replay must stay read-only or otherwise tightly controlled. Recovery paths should assume that:

  • consumers may see the same event again
  • derived state may need rebuild or reconciliation
  • side effects must be idempotent or signoff-gated

4. Use event modeling after the sourcing boundary is clear​

Event Modeling explains event families, dependency graphs, and projection/catalog relationships.

It does not replace the event-sourcing truth that explains:

  • why events remain append-only
  • why replay must be safe
  • why projections are rebuildable instead of canonical

Verification​

This page is being applied correctly when a reader can:

  1. explain why the event log is canonical and projections are derived
  2. distinguish replay preview from a state-mutating recovery action
  3. identify where idempotency matters before automating or rebuilding

Common failure modes​

Treating a projection as source truth​

Problem:

  • recovery, reconciliation, and debugging decisions get anchored to a convenient summary instead of the real event history.

Better path:

  • start from event truth, then verify what the projection derived from it

Confusing event sourcing with event modeling​

Problem:

  • route catalogs and dependency graphs are read as if they defined the write-truth model.

Better path:

  • read Event Sourcing for append-only, replay, and idempotency boundaries first, then use Event Modeling for family and dependency explanation

Source Truth​

Next paths​