An offset marks a consumer’s progress through an ordered event or message sequence. Persisting that marker lets processing resume from the recorded position rather than treating every restart as a fresh read. section 14.1 section 14.1.2
Offsets are scoped to the consumer that owns them. In Kafka, each consumer group has its own offset: after consuming a batch, committing the offset records that group’s last-read position. A plain consumer does not commit by default, so it cannot automatically continue where it stopped after restart. section 14.1
Projecting journal events into a read-side table
A cargo projection creates one projection per tag. With no stored offset, each projection reads matching journal events from the beginning. As it handles events, it updates the cargo-count table and stores a current offset matching the journal sequence number for that tag. Later events advance both the read-side data and the stored position. section 10.4
Offset handling determines restart and delivery behavior:
- Leave an offset uncommitted, and a restarted Kafka stream starts at the topic’s end rather than resuming prior progress. section 14.1.2
- Enable automatic commits to preserve progress, with the stated limitation that an application crash during a transaction can still affect processing. section 14.5
- Use a committable Kafka source for at-least-once processing, ensuring no message is lost even though a message can be processed more than once. section 14.5
- Use an exactly-once projection to have projection machinery read journal offsets and recover its progress after a crash. section 10.3
Table 10.6 akka_projection_offset_store for projections (view table figure)
The offset store shows separate current offsets for projection tags, making progress visible as durable state rather than an in-memory counter. section 10.4
An offset is not the business result of processing; it is the checkpoint that coordinates reading with that result. For projections, the checkpoint follows journal sequence numbers. For Kafka consumers, it follows topic consumption for a group. Choose commit and delivery semantics according to whether duplicate processing, lost messages, or crash recovery matters most. section 10.3 section 14.5
