4 ms·
If most of the callers did need both pieces of data it would have made sense to combine them into a single service. But, overwhelmingly, callers are interested
by bedobi 6y ago
If most of the callers did need both pieces of data it would have made sense to combine them into a single service. But, overwhelmingly, callers are interested in one piece of data or the other, and the load profile, tolerance for staleness in caching etc etc for each of the two services are vastly, vastly different. This is why we chose to split the two into different services.
The few callers that do need to obtain both pieces of data just make concurrent calls to both and them zip them into a single result.
- lowtech 6y agoSounds 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.