[new rule] producers must specify order guarantee in AsyncAPI spec

[BirgitBader]

(i) This issue has been manually transferred from a former internal repository, as a private repository issue cannot be transferred to a public repository.

Context

If the producer guarantees that messages are not sent out-of-order, consumers can more easily consume topics.

This ticket explores if this needs to be part of the contract between the producer and consumer (i.e. AsyncAPI spec).

[BirgitBader]

Comment history

Mar 16, 2022 by @thake

If this should be documented in AsyncAPI, it may be better to call it x-deliveryGuarantees which is an array of DeliveryGuarantees.
A DeliveryGuarantee is one of these: in-order, no-duplicates. This leaves it open to extensions.

Mar 16, 2022 by @thake

@otto-ec/async-group How is this currently handled? Is there a way that producers specify if they are making sure that events are sent to the queue/topc in order? Does this seem to you like a reasonable thing to document in the contract?

Mar 16, 2022 by @maxedenharter0507

For SNS/SQS based APIs: Standard SNS and SQS does not keep the order of events. For that usecase there is FIFO SNS/SQS which is not compatible with standard SNS/SQS. AFAIK there is no bigger producer which uses FIFO SNS/SQS for public/external APIs. Because of that i think no producer is able to keep the order of events.

Mar 16, 2022 by @thake

With kafka this would be possible using the idempotent producer feature: https://blog.clairvoyantsoft.com/unleash-kafka-producers-architecture-and-internal-working-f33cba6c43aa

Mar 17, 2022 by @slinstaedt

What scope of order are we talking about?
Kafka guarantees strict FIFO on a partition and therefore also on message key basis, which is enough to guarantee happens-before relation for important transactional units like aggregates, given the producer is also serializing command processing for these units, which is desirable even without kafka.
Global message ordering is a different beast though and is hard to archive without killing scaling capabilities.

Mar 18, 2022 by @thake

I'm just talking about ordering guarantees on a partition basis, but again this depends on the chosen transport. Kafka only guarantees strict FIFO on partitions if the producer is configured to be idempotent (see https://docs.confluent.io/platform/current/installation/configuration/producer-configs.html#producerconfigs_retries).
Right now I'm leaning towards not including a rule for this for the MVP guidelines.

Mar 18, 2022 by @slinstaedt

Sorry, of course strict FIFO only for idempotent configured consumers.
I leaning in the same direction. If domain event processing in-order or with no-duplicates are mandatory, because for the event's domain out-of-order or duplicates processed events make a reasonable difference, providers should provide capabilities that enable consumers to implement something in this regard themselves. A sequence number could help to do so.

Mar 25, 2022 by @thake

We agreed to specify order guarantees in the AsyncAPI spec. The rule needs to explain why order-guarantees are hard.
Best Practice: Should monitor dropped events.

Mar 30, 2022 by @thake

Currently put on hold because I need a sparring partner to discuss the nitty details of this rule even more. As this is not part of the MVP, it is put on pause.

Mar 30, 2022 by @thake

Already produced content can be found in branch https://github.com/otto-ec/ottoapi_guidelines/tree/feat/producer-garantuees