Postgres offers a few primitives to help with queues- SELECT FOR UPDATE SKIP LOCKED https://tnishimura.github.io/articles/queues-in-postgresql/

Doesn’t scale greatly but it’s a good start. Polling the db every few seconds should be ok

Polling can probably be avoided with listen + notify used in triggers.

I can recommend the queues in postgres approach too, works great.

Since "complication" is the opposite of "simplification", it can't happen. But it's possible with "complecting" - if the separation of concerns was ill-advised in the first place.

Monoliths (in some cases)?

I am pretty sure that complicating things could be done in some cases to improve performance, trading better performance for more entanglement/dependencies between different parts of the code.

Yes, it's somewhat common to inline/intertwine things for performance e.g. for a program that parses an input, analyzes it and then presents a report, you might be tempted to analyze or report stuff as soon as it's parsed

Or a later step could be written in a way that assumes some other additional data or intermediate results have been computed earlier, and passed along, and the format of that extra data becomes a separate thing from the bare minimum data that could be passed from step A to step B that makes A and B less easy to change independently.

tr-8s and a modular synth setup, nice!

definitely liked it, I appreciate world sounds :drum_with_drumsticks: