Listeners Overview
A listener runs when a matching event is emitted — before the ledger append completes. It can resolve related entities and mutate their state in-process, with no Kafka lag.
Use listeners for atomic cross-entity consistency. Use projections for queryable read models. Use side_effects for async fan-out.
How listeners fit into the write path
Listeners sit between emit and ledger commit. Projections consume after Kafka.
Declaring listeners
# app.causet
includes:
listeners: [./listeners/**/*.listeners.causet]listeners:
- on: ARTIST_FOLLOWED
resolve:
artist: lookup(artist, event.payload.artist_id)
mutate:
- op: add
path: /follower_count
value: 1
on: artistIn this section
| Page | What it covers |
|---|---|
| Concept | Listener vs projection vs side_effects |
| Defining Listeners | on, where, resolve, mutate, ordering |
| Best Practices | I/O, cycles, when not to use listeners |
| Examples | Scoring and follow-counter patterns |
Next steps
- Intents — where events are emitted
- Projections — async read models
- Workflows —
submitandschedulein side_effects