sergF

4 ms·

1.
by sergF 7mo ago
Thanks for the link, DBOS looks interesting. Durable execution seems to be exactly the problem space here. Most approaches keep the executor inside the app and use the DB for coordination, which works but still means rebuilding similar infr
2.
by sergF 7mo ago
The transactional enqueue issue is exactly what makes me unsure about the callback model. With in-app queues you get the nice property that the job can be created in the same DB transaction, which is harder to keep once the runner lives out
3.
by sergF 7mo ago
Yeah, that's usually when async becomes unavoidable for me too — long tasks, retries, scheduling. Even with Postgres queues I still end up doing a fair bit of setup, which makes me wonder if this should live outside the app.
4.
by sergF 7mo ago
Yes, I've seen a lot of Postgres-based queues lately too. Even without Redis I still end up rebuilding some kind of job system on top of the DB, which is why I'm wondering if this should live outside the app entirely.
5.
by sergF 7mo ago
Yeah, that makes sense too. I also try to keep things synchronous as long as possible. In practice async usually shows up once there are external APIs, retries, scheduling, or anything that shouldn't block the request, and that's
6.
by sergF 7mo ago
That makes sense, and this is actually close to what I keep ending up with in different projects. I usually start with something simple, then add a task table, then locking, retries, then some kind of worker process, and eventually it turns
7.
by sergF 7mo ago
Yeah, this is pretty much what I end up doing as well. It works, but I keep rewriting the same task table / locking / retry logic in every project, which is why I'm wondering if it makes sense to move this out into a separate
8.
Ask HN: Do you still run Redis and workers just for background jobs?
2 points by sergF 7mo ago|15 comments