Comment by sorentwo

2 days ago

Postgres LISTEN/NOTIFY was a consistent pain point for Oban (background job processing framework for Elixir) for a while. The payload size limitations and connection pooler issues alone would cause subtle breakage.

It was particularly ironic because Elixir has a fantastic distribution and pubsub story thanks to distributed Erlang. That’s much more commonly used in apps now compared to 5 or so years ago when 40-50% of apps didn’t weren’t clustered. Thanks to the rise of platforms like Fly that made it easier, and the decline of Heroku that made it nearly impossible.

17 comments

sorentwo

Reply
nightpool  21 hours ago

What about Heroku made Erlang clustering difficult? It's had the same DNS clustering feature that Fly has, and they've had it since 2017: https://devcenter.heroku.com/articles/dyno-dns-service-disco....

  • sorentwo  21 hours ago

    The problem was with restrictive connections, not DNS based discovery for clustering. It wasn't possible (as far as I'm aware) to connect directly from one dyno to another through tcp/udp.

cpursley  2 days ago

How did you resolve this? Did you consider listening to the WAL?

  • sorentwo  2 days ago

    We have Postgres based pubsub, but encourage people to use a distributed Erlang based notifier instead whenever possible. Another important change was removing insert triggers, partially for the exact reasons mentioned in this post.

  • parthdesai  2 days ago

    Distributed Erlang if application is clustered, redis if it is not.

    Source: Dev at one of the companies that hit this issue with Oban

alberth  2 days ago

I didn’t realize Oban didn’t use Mnesia (Erlang built-in).