4 ms·
Sounds like you have a simple system, in which case the separation have few drawbacks. It's not uncommon for a customer to ask for a report that to be generated
by lowtech 6y ago
Sounds like you have a simple system, in which case the separation have few drawbacks.
It's not uncommon for a customer to ask for a report that to be generated needs to span dozens of tables. Or to save a DTO object that will trigger multiple microservices (and a lot of validations, transactions, rollback, etc). Business rules can be very complex and entangled in some shops.
- yakshaving_jgt 6y agoI'd say it sounds like they have a distributed monolith :)
- nine_k 6y agoGood thing if your data fit into a single database; sometimes they do not, because they are too big. OTOH you can often export the data in different, more appropriate ways to make your joins more efficient.
- bedobi 6y agoIt's not a simple system, we have all those things and more. But when we make a service that contains partner user profiles data we optimize for that (=millions of partners accessing their profiles, has to respond immediately and scale infinitely, has to be easy and quick to capture new details like eg mfa preference app vs sms etc), not peripheral things like reports etc - such things have to live life being harder for them than they would be if we had a monolith.