Kafka is Fast – I'll use Postgres

Re:Kafka is Fast – I'll use Postgres by bccdee on Friday October 31, 2025 @11:32AM (#45773199)

> It's trivial to ensure that only one message is delivered to only one consumer if that's what you want. Consumer groups track their offset and then commit the offset, the message stays in Kafka but it won't be read again. This IMO is better behaviour than RabbitMQ

The trivial solution is to use Kafka. They're clearly saying that Kafka makes it trivial, not that it's trivial to solve from scratch.

[ Parent | on HN ]

Re:Kafka is Fast – I'll use Postgres by otterley on Friday October 31, 2025 @06:56PM (#45777623)

What the parent poster described isn’t what makes Kafka’s “exactly once” semantics work. It’s the use of an idempotency token associated with each publication, which effectively turns “at-least-once” semantics into effectively “exactly once” via deduplication.

[ Parent | on HN ]

Re:Kafka is Fast – I'll use Postgres by saberience on Monday November 03, 2025 @11:38AM (#45800998)

We used Flink and S3 compatible backends (for the Flink state) to ensure exactly once processing.

I didn't say Kafka magically solves these problems for you, but it was required for the scalability we needed.

[ Parent | on HN ]