NATS Jetstream
Message Ordering
Key-Based Ordering
Messaging Systems
Distributed Systems

Does NATS Jetstream provide message ordering by a key?

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

NATS Jetstream, an advanced messaging system that extends the NATS messaging protocol, introduces functionalities centered around persistence, at-least-once delivery, and stream processing. One critical aspect that many systems rely on is the ability to ensure message ordering based on a specific key. This feature is crucial when messages must be processed in the order they were created relative to specific criteria, such as a user ID or transaction sequence.

NATS Jetstream and Message Ordering

Out of the box, NATS Jetstream ensures message ordering within a stream. This means that messages are stored and can be consumed in the order they were received. However, this ordering is global to the stream and not specific to a partitioning key as seen in some other messaging systems like Apache Kafka.

Ensuring Message Ordering by Key

To achieve ordering by a specific key within NATS Jetstream, you must engineer around this by designing your system in a way that supports such a feature. Here are common strategies:

1. Sharding by key

One method is to shard or partition data by key across multiple streams. Each stream can represent a key range or individual key. This method ensures that all messages for a specific key are routed to the same stream, maintaining order within that shard. However, managing and scaling a large number of streams can become complex.

2. Consumer-side Ordering

Another approach involves handling ordering at the consumer level. This technique leverages the consumer's logic to reorder messages based on their keys as they arrive. While this allows greater flexibility and might simplify stream management, it places a heavier processing requirement on the consumer and can lead to higher latency or complexity in message handling logic.

3. Combination of NATS Features

Using a combination of NATS subject-based messaging and Jetstream, you could implement a system where messages are published on specific subjects based on their key and consumed from a Jetstream. While this leverages the inherent capabilities of NATS for routing, the actual ordering and concurrency handling must be carefully designed.

Technical Example

Here’s a simple technical concept on how to implement sharding by key using NATS Jetstream:

bash
# Create different streams for different key ranges or keys
nats stream add orders_key1 --subjects "ORDERS.key1"
nats stream add orders_key2 --subjects "ORDERS.key2"
bash
# Publish messages to specific streams based on the key
nats pub ORDERS.key1 '{"orderId":123, "item":"apple"}'
nats pub ORDERS.key2 '{"orderId":124, "item":"banana"}'

Each stream maintains the order of messages as they are received.

Summary Table

StrategyComplexityScalabilityMaintain Order per KeyAdditional Overhead
Sharding by keyMediumHighYesHigh (many streams)
Consumer-side orderingLowMediumYesMedium (logic in consumer)
Combination of NATS featuresMediumHighYesMedium (stream and subject management)

Conclusion

While NATS Jetstream does not natively support message ordering by key, it is possible to engineer solutions using Jetstream's basic capabilities combined with careful system design. The method you choose depends on your specific use case, scalability needs, and the complexity you are willing to manage. Each of the strategies mentioned provides a different balance of complexity, scalability, and overhead, allowing you to tailor your implementation to your requirements.


Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

All Rights Reserved.