kpmah

I watch this show, but one of the most annoying things about it is that the traitors are incentivised to murder the smartest, most intuitive players first, leaving people they can manipulate easily. Maybe you could argue the smartest move is to play dumb.

This is at its worst in the second Australian season, which is an incredibly frustrating watch.

Author here, 8 years on.

Although the advantages are real, I can't say I have had much opportunity to implement schemas like this. The extra complexity is usually what gets in the way, and it can add difficulty to migrations.

I think it would be useful in certain scenarios, for specific parts of an application. Usually where the history is relevant to the user. I think using it more generally could be helped by some theoretical tooling for common patterns and data migrations.

Another misconception is that they somehow scale horizontally "better". They do let you scale components independently of each other, but this isn't as useful as a lot of people seem to think it is.

Even if it doesn't directly cause extinction, it could do things like destabilise nuclear powers.

Obviously you're in a better position to evaluate the trade-offs for your application than I am, so I'm not saying your decision is wrong, but this can potentially decrease availability if your application depends on both PostgreSQL AND Redis to be available to function.

To spell out good reasons for doing this:

If you're already using Postgres, you can avoid increasing operational complexity by introducing another database. Less operational complexity means better availability.

You can atomically modify jobs and the rest of your database. For example, you can atomically create a row and create a job to do processing on it.

I'm a type enthusiast, but dynamic languages make a lot of sense for small programs that either give you an immediate answer or fail to run (i.e. not long running, few branches).

In those cases, the difference between a compile-time check and a run-time check is much smaller.

I've worked at a place where this was cargo-culted and it worked horribly. All the worst aspects of 'services-first' design.

I think this works much better when each team is working on what could be regarded as a complete end-to-end product e.g. a database. It works poorly when each team is working on part of a product.