Since your potential "database synchronization" has nothing to do with Kafka itself - there's little incentive of using Spring Kafka's @RetriableTopic there: it's not Kafka's fault, it's your processing part.

It's failure of a downstream counterpart Kafka has no knowledge about and or connection to, and if it fails the ways you describe (e.g. constraint violation), there's little expectation it will improve before attempts.

I would suggest to catch an error, and then drop the message into some kind of makeshift DLQ/DLT (even republish to back to the same Kafka cluster but other topic). From that point on you can either automate processing of that DLQ, or do it manuyally, or both.

I assume you use @KafkaListener upon your processing logic POJO, hence you can either catch that right within the processing method, or use one of two layers of error handlers (make sense to start with KafkaListenerErrorHandler implementation, it works at listener method level).

If you, however, have reasonable expectations conditions that caused error at your "internal database" side can improve between takes - you can go ahead & configure yourself non-blocking retries with @RetriableTopic.

That would automate republishing of problematic messages into special retry topics & finally to DLT when all retry attempts are exhausted.

P.S. Also, you may consider to switch to manual acknowledgements in any of cases mentioned above to have fine control of when & how you submit offsets back.