Where does the retry go in case of an optimistic locking version conflict — from the Kafka message or from the service?

When using optimistic locking, retry is usually initiated at the service level, not Kafka message level.

The reason is that Kafka guarantees message delivery but does not manage business logic and data conflicts. If, during message processing, the service detects a version conflict (for example, when updating a record with optimistic locking), it can:

• Retry within the service itself, attempting to apply changes with the current data version.
• Or, if retry is not possible or the limit is exceeded, log the error and handle it separately.

Thus, retry does not occur at the Kafka level (the message is not automatically resent), but is controlled by the logic of the service that processes the message.