It might be impossible unless there is a proper backend-level support for this (what does not appear to be the case today in known libraries).

Basically the producer can do batches and in theory a batch sent before could fail while a next batch sent just after it would succeed (breaking your ordering). In Java you can control it via max in-flight request config.

So it'd be all-or-nothing, but on a batch level - and you'd submit another batch for production only after the previous one had succeeded.

This also means you'd need to pay careful attention that your producer is working with only one batch at a time - the API is not perfect (as it takes single message and then it decides to batch on its own), but you could for example fork and enhance it.

What you don't want to happen is a situation when you submit e.g. 5 (large) records, they get into batches of [1, 2, 3] and [4, 5], first batch fails, second succeeds. You might need to get some extra visibility into producer's internal batcher workings (and/or enhance it yourself).

Having said all of that, why not implement business-level sequence id and do handling on the consumer level?