zlacker

In my experience proper abstraction is the key. If you have a clear abstraction and structure you can replace the implementation when you need to without too much disruption. If it’s too leaky you’re screwed.

>>2muchc+(OP)
100%! Create a good enough solution and put it behind an abstraction that remains stable when you later create an ideal solution

>>2muchc+(OP)
Yes. Use a queue abstraction for which there are numerous queues available off the shelf for!

>>2muchc+(OP)
In my experience, great abstractions without a good data migration blueprint is as about as useful as no abstraction at all.

In this example - great, you have a “queue” abstraction. When you switch to RabbitMQ or Postgres, how do you move your existing data without a quality of service or data loss? It can be difficult with production datastores even if the abstraction within your service is beautiful.

>>aparso+P7
Isn't migrating a queue super simple? Have a window in which you only add to the new system and you listen to both. When the old queue is empty, delete it.

If you need to keep track of old data, then yes, migration is hard. But queues don't save old data—that's the point of a queue.