Redis Stream - Order Guarantee of the events

Question

I have used Kafka. In Kafka, order of the event is guaranteed by using id. Do we have anything similar in Redis? If I have order-events stream and multiple consumers in a consumer group, all the events related to one particular order should be processed sequentially.

---

Event - A message / Notification / anything that happened which needs to be announced. Like order created event, order cancelled event.

---

To be more clear,

Lets assume user1 orders a product called ABC1 via order-service. This order-service publishes an purchase-order-related stram. The user1 modifies/updates the quantity of ABC1 for which the order-service publishes another event in the same stream as a second message. Here the ID of the messages could be different. But is there any guarantee that these 2 messages will be processed by 1 single consumer in a consumer-group when there are multiple consumers? Because these 2 messages/events are related and should be processed sequentially. Kafka provides the guarantee by partitioning by using the order-id of the ABC1 product purchase.

Answer 1

Disclaimers:

• this answer assumes that you are referring to Redis Streams (introduced in Redis 5.0).
• I'm not sure what do you mean by "event", I commented in the OP asking for clarifications. I'll try to answer without this clarifications and edit my answer once you clarify the concepts. See my edit at the end.

Redis Streams' IDs also uses a sequential ID, as explained in the XADD command documentation:

IDs are specified by two numbers separated by a - character [...]
Both quantities are 64-bit numbers. When an ID is auto-generated, the first part is the Unix time in milliseconds of the Redis instance generating the ID. The second part is just a sequence number and is used in order to distinguish IDs generated in the same millisecond.
IDs are guaranteed to be always incremental

Since Redis Server is (mostly) single-threaded, the requests are processed in the same order that the Redis server receives them, and no new request are processed until the last one was answered.

However, network issues can influence in this. Consider the following (NETWORK is when the message is in transit):

Time    Cli1        Cli2        Redis Server
   1    XADD -----------------> Processing Cli1 Request
   2            NETWORK <------ Answer: ID 1
   3                XADD -----> Processing Cli2 Request
   4                ID 2 <----- Answer: ID 2
   5    ID 1 <--NETWORK

If Cli1 and Cli2 compare their answers and the receive time, it seems that the Server processed the requests in the wrong order, but for the server it's everything ok.
Also, if Cli2 request arrived while the server was processing Cli1 request, it would wait until the Cli1 processing finished to start processing Cli2.

Edit after the OP edited the question

In the section Differences with Kafka partitions of the Introduction to Redis Streams documentation page, it is stated that:

If you use 1 stream -> N consumers, you are load balancing to N consumers, however in that case, messages about the same logical item may be consumed out of order, because a given consumer may process message 3 faster than another consumer is processing message 4.

So basically Kafka partitions are more similar to using N different Redis keys. While Redis consumer groups are a server-side load balancing system of messages from a given stream to N different consumers.

So, the Consumer Groups feature in Redis does not serve to the same purpose of Kafka's.

It is possible to make the kind of grouping you want by using multiple Redis keys and marking each consumed order, but (AFAIK) Redis doesn't provide this feature so you need to implement it by yourself.