Event Processors: Subscribing vs Tracking

A subscribing event processor receives events synchronously, on the very same thread that published them, the instant they're applied inside a command handler. There's no queue, no separate worker, no delay — the event handler's code runs as a direct continuation of the command that produced the event, before that command is considered fully handled.

This immediacy sounds appealing at first: it guarantees that by the time the original command "returns," every subscribing handler listening for that event has already finished running. For a system that genuinely needs a read model updated before it responds to the caller, that guarantee is useful. But it comes at a real structural cost — the projection's own performance now sits directly on the critical path of the command that triggered it.

Because a subscribing processor runs entirely in memory, on the thread that's already there, it also has no way to recover a lost position. If the application crashes moments after an event was applied but before every subscribing handler finished, there's no durable record of "how far" that handler got — it simply starts fresh on the next event it happens to see, with no memory of what it missed while the process was down.

A tracking event processor runs on its own, separate thread and keeps a durable record — called a token — of exactly which event it processed last for a given segment of the event stream. This single design choice decouples the projection's speed entirely from the command's speed: the original command finishes as soon as its event is durably stored, full stop, and the tracking processor catches up afterward, on its own schedule, at whatever pace it can actually sustain.

That token is more than a performance detail — it's what makes several other capabilities possible at all. Because the processor always knows precisely which event it last handled, it can resume from that exact position after a restart instead of starting over, and it can be told to rewind and replay a stream from any earlier point, including the very beginning, entirely on command.

Property	Subscribing	Tracking
Timing	Synchronous — runs inline with the command	Asynchronous — runs on its own thread, its own pace
Can replay history?	No	Yes — the token remembers exactly where it left off
Can run in parallel, across threads?	No	Yes — work can be split across segments for higher throughput
Recovers its position after a restart?	No — starts fresh	Yes — the stored token says exactly where to resume

Axon defaults every event processor to tracking mode, and for most projections that default is the right call — the decoupling, replay support, and restart recovery it provides are valuable for nearly any read model you'll build. You can still be explicit about the mode per processing group, which is good practice once a service has more than one projection with different needs.

Use	When
Tracking (the default, and the sensible starting point)	Almost always — the decoupling, replay support, and restart recovery are genuinely valuable for nearly every real projection, including the customer, account, card, and loan read models in a typical bank system.
Subscribing	Only when a projection update must be guaranteed complete before the original command's response returns — a narrow, specific requirement, not a general-purpose choice.

Configuring the mode is a one-line change per processing group in application.yml, naming the processing group you want to affect:

axon:
  eventhandling:
    processors:
      account-projection:
        mode: tracking   # or "subscribing"

A processing group is simply the name Axon uses to bucket a set of event handler methods together under one processor. By default, that name comes from the class's package, but it's common to set it explicitly with @ProcessingGroup("account-projection") on the component so the configuration key above lines up predictably, independent of how the code happens to be packaged.

@ProcessingGroup("account-projection")
@Component
public class AccountProjection {

    private final AccountViewRepository repository;

    public AccountProjection(AccountViewRepository repository) {
        this.repository = repository;
    }

    @EventHandler
    public void on(AccountOpenedEvent event) {
        AccountView view = new AccountView();
        view.setAccountId(event.getAccountId());
        view.setCustomerId(event.getCustomerId());
        view.setBalance(event.getInitialBalance());
        repository.save(view);
    }
}