Is "exactly once" delivery guarantee a bit of a misnomer?

[bottlenecked]

Hi there! I was browsing through the docs and I noticed this:

In the core_concepts.mdx file it's mentioned that

To provide exactly-once processing, Sequin requires that every message delivered to a consumer is acknowledged.

Later on however the docs state

If webhook endpoint does not respond before the request timeout elapses, Sequin will cancel the request and retry.

This seems to me like a bit of a contradiction: if the consumer has received the first messaged but failed to acknowledge, at some point Sequin will decide to resend.

Doesn't that make it into an "at least once" delivery, and wouldn't unique message ids be required in that case for the clients to be able to idempotently process messages?

PS: cool project for people looking to minimize infra - but the Redis dependency kinda sours it

[acco]

Hey @bottlenecked !

The key difference is between exactly-once processing and exactly-once delivery. I agree, we're an at-least-once delivery system. I believe we use these terms correctly in our docs, but if you spotted anywhere we got them confused let me know. Processing being delivery, do work, ack.

We like to focus on the processing bit, as that's usually what people care about (I want to do this workload once).

At the end of the day, perfect exactly-once mechanics are a platonic ideal. And a system can only bring you so far, at some point you must implement idempotency on the client if your requirements demand it.

I'm curious how the Redis dependency sours it? Our read is that both Postgres and Redis are readily available turn-key by all cloud vendors. The neat part is that if Postgres can handle your workload, then Redis will have no trouble keeping pu. i.e. you won't be bottlenecked by Redis (😉)

[bottlenecked]

I see.. I admit this is the first time I hear about this nuance (processing vs delivery) so now I'm glad I opened the ticket because I learned something new 😄

Redis (esp. for small teams) is just another piece of infrastructure that can complicate things in production. Postgres... I guess we already bought into it so it doesn't count.