History

While Kafkorama is designed for real-time messaging, some messages are retained in memory for a configurable period of time, as described below.

Snapshot Messages

For each subject X, every node in a Kafkorama cluster maintains a snapshot message — the most recent message received with the retained property set to true. This applies to both clustering modes: Standard Message Delivery and Guaranteed Message Delivery.

The table below illustrates how the snapshot message for the subject /Stocks/NYSE/IBM evolves as new messages are received:

Time Received Message Snapshot Message
10:12 (first message) subject=/Stocks/NYSE/IBM
content=140
retained=false
No snapshot available
for /Stocks/NYSE/IBM at this time
10:13 subject=/Stocks/NYSE/IBM
content=150
retained=false
No snapshot available
for /Stocks/NYSE/IBM at this time
10:15 subject=/Stocks/NYSE/IBM
content=141
retained=true
subject=/Stocks/NYSE/IBM
content=141
retained=true
10:25 subject=/Stocks/NYSE/IBM
content=144
retained=false
subject=/Stocks/NYSE/IBM
content=141
retained=true
10:40 subject=/Stocks/NYSE/IBM
content=142
retained=true
subject=/Stocks/NYSE/IBM
content=142
retained=true

When a client connects or reconnects to a node in the Kafkorama cluster and subscribes to a subject, that node first sends the current snapshot message (if available). Subsequently, the client receives any new real-time messages for that subject as soon as they are published, including messages originating from Kafka.

Note: By default, snapshot messages are retained in memory indefinitely. You can configure a retention time using the SnapshotExpireTime parameter. This is especially useful when new subjects are continuously added but not updated afterward — without a time limit, unused snapshots could accumulate and lead to memory issues.

Historical Messages

For clusters using Guaranteed Message Delivery, each node in the cluster maintains a history of recent messages for each subject. If a client experiences a failure and reconnects, it automatically retrieves missed messages from this history. These recovered messages are marked with the recovered message type (see the Messages section).

Additionally, the client libraries provide a method to request a number of historical messages before receiving real-time updates:

void subscribeWithHistory(
  List<String> subjects, 
  int numberOfHistoricalMessages
)

If the REST Client Interface is enabled, you can retrieve a snapshot message for a subject via a HTTP Request as shown here.

Note: By default, historical messages for a subject are kept in memory for up to 180 seconds — enough for typical reconnection delays. You can change this duration using the CacheExpireTime parameter, and limit the number of stored messages per subject using the parameter MaxCachedMessagesPerSubject.
© 2025 MigratoryData. All rights reserved.