41–50 of 82 posts
Having SEPARATE DLQ and Event/Message broker systems is not (IMO) valid - because a new point of failure is being introduced into the architecture.
Earlier quoted context omitted.
We just published a detailed walkthrough of this exact pattern with concrete examples and failure modes: PostgreSQL FOR UPDATE SKIP LOCKED: The One-Liner Job Queue https://www.dbpro.app/blog/postgresql-skip-locked It covers the race condition, the atomic claim behaviour, worker crashes, and how priorities and retries are usually layered on top. Very much the same approach described in the old 2ndQuadrant post, but wi…
Love your product. Will you ever provide support of duckdb/motherduck? Wish there is a generic way you provided to add any database type
DuckDB is on our radar. In practice each database still needs some engine-specific work to feel good, so a fully generic plugin system is harder than it sounds. We are thinking about how to do this in a scalable way.
Biggest thing to watch out with this approach is that you will inevitably have some failure or bug that will 10x, 100x, or 1000x the rate of dead messages and that will overload your DLQ database. You need a circuit breaker or rate limit on it.
The idea behind a DLQ is it will retry (with some backoff) eventually, and if it fails enough, it will stay there. You need monitoring to observe the messages that can't escape DLQ. Ideally, nothing should ever stay in DLQ, and if it does, it's something that should be fixed.
The idea is that if your DLQ has consistently high volume, there is something wrong with your upstream data, or data handling logic, not the architecture.
Postgres is essentially a b-tree with a remote interface. Would you use a b-tree to store a dead letter queue? What is big O of insert & delete? what happens when it grows? Postgres has a query interface, replication, backup and many other great utilities. And it’s well supported, so it will work for low-demand applications. Regardless, you’re using the wrong data structure with the wrong performance profile, and at…
Earlier quoted context omitted.
The other system you're using that isn't Postgres can also go down. Many developers overcomplicate systems. In the pursuit of 100% uptime, if you're not extremely careful, you removed more 9s with complexity than you added with redundancy. And although hyperscalers pride themselves on their uptime (Amazon even achieved three nines last year!) in reality most customers of most businesses are fine if your system is dow…
>The other system you're using that isn't Postgres can also go down. Only if DC gets nuked. Many developers overcomplicate systems and throw a database at the problem.
lol a FOR UPDATE SKIP LOCKED post hits the HN homepage every few months it feels like
and another CTO will use this meme as a reason to "just use Postgres" for far longer than they should lmao
Using Postgres too long is probably less harmful than adding unnecessary complexity too early
Earlier quoted context omitted.
>The other system you're using that isn't Postgres can also go down. Only if DC gets nuked. Many developers overcomplicate systems and throw a database at the problem.
Wow, TIL there was an atomic attack on the capitol in October!
DC!=Washington, DC
Earlier quoted context omitted.
and another CTO will use this meme as a reason to "just use Postgres" for far longer than they should lmao
I’ll take “just use Postgres” over “prematurely add three new systems” any day. Complexity has a cost too. Using Postgres too long is probably less harmful than adding unnecessary complexity too early
Both are pretty bad.
Earlier quoted context omitted.
The other system you're using that isn't Postgres can also go down. Many developers overcomplicate systems. In the pursuit of 100% uptime, if you're not extremely careful, you removed more 9s with complexity than you added with redundancy. And although hyperscalers pride themselves on their uptime (Amazon even achieved three nines last year!) in reality most customers of most businesses are fine if your system is dow…
>The other system you're using that isn't Postgres can also go down. Only if DC gets nuked. Many developers overcomplicate systems and throw a database at the problem.