Skip to main content

Event Versioning

When you need to make breaking changes to an event, use versioning in the event name:

Approach 1: Version Suffix

Pros: Clear version indicator
Cons: Requires updating all subscribers

Approach 2: New Event Name

Pros: Old and new events coexist
Cons: Need to maintain both during transition

Approach 3: Additive Changes

Add new fields without removing old ones:
Pros: No version changes needed
Cons: Payload grows over time

Best Practices

Keep Payloads Small

  • Only include essential data
  • Reference IDs instead of embedding full objects
  • Use separate events for different concerns

Use Idempotency

Always check the idem field to avoid processing duplicates:

Handle Replayed Events

Check metadata.$internal.replay_info.isReplayed to detect replays:

Design for Failure

  • Always use manual ACK mode for critical events
  • Implement retry logic with defer
  • Use discard for permanently invalid events
  • Monitor failed events in the Logs dashboard

Common Patterns

Event Chaining

One event triggers another:

Batch Processing

Option 1: Acknowledge and Collect Process events in batches by acknowledging immediately:
Option 2: Use Multiple Workers Run multiple workers to process events in parallel:
You must ack/defer/discard each event to receive the next one. For high throughput, use multiple workers instead of holding events unacknowledged.