4 ms·

…until you need to market to people who didn't get a shipping last month, delay shipping until at least one recharge attempt, or ship before charging for custom

…until you need to market to people who didn't get a shipping last month, delay shipping until at least one recharge attempt, or ship before charging for customers you're reasonably sure will pay anyway. Business changes, and putting rigid firewalls in place without seeing an established pattern of change and without established need for that is a bad idea. One global database buys you a lot (easy data access, easy transaction consistency, simple locks, even transactional notifications), and you can take it very far performance wise, throwing that away just in case you might need more performance later seems unwise.

wild_egg 3y ago
> …until you need to market to people who didn't get a shipping last month, delay shipping until at least one recharge attempt, or ship before charging for customers you're reasonably sure will pay anyway. These are all very simple things to handle when services encode processes instead of entities > Business changes Yes, and then you throw away the code for that outdated process and encode the new one. > One global database buys you a lot Absolutely, this is the correct choice for probably 95+% of companies. I will always argue in favour of a monolith and single database. If someone is dead set on microservices though, they'll avoid a world of pain by actually designing them properly