> I find data organization to be a direct consequence of service interface.
Then, you will not like microservices. Microservices make it harder, not easier, to organize data.
You have to worry about problems such as eventual consistency, and figure out how to join data across multiple data sources.
It compounds the problem significantly, and the only thing it gives you is that it forces you to silo data. That can be a good thing, but it doesn't solve the data organization problem.
Usually the service structure will mirror the team structure, e.g. one team of 2-6 SWEs per service. I've enjoyed doing things this way now that we're out of the monolith.
BTW, monolith DB has its own form of eventual consistency. Process A puts data into DB, process B picks it up later and affects the DB. There's no reasonable way that everything in such a multi-use DB is always logically in agreement. You're just guaranteeing that B sees what A writes immediately, which comes at a cost.
> the only thing it gives you is that it forces you to silo data
It gives you a smaller blast radius when something goes wrong, avoids over-stressing a single DB, alleviates single points of human dependency like the DB curator, lets you scale separate pieces independently, and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.
Sure, but likely that team is not working on a single service when people say microservices. That could be SOA, which is more my preference, but definitely not a microservice going by the most popular definition which is "small enough to rewrite."
> BTW, monolith DB has its own form of eventual consistency.
Sure, on very large systems. Microservices always have this - even tiny systems.
> It gives you a smaller blast radius when something goes wrong,
At the cost of often having a much harder time fixing things when they do go wrong :)
> avoids over-stressing a single DB,
Monoliths can use as many databases as they want! And you can use a single DB with a microservice architecture across many microservices (tho I think this is an anti-pattern, teams often do it).
> alleviates single points of human dependency like the DB curator,
I haven't been at a job that has a DB curator, but it compounds the "bob wrote those ten services in rust, who... who knows rust? anyone?" issues :)
> lets you scale separate pieces independently,
You can do this with a monolith with many technologies, though seems easier to do for a microservice as a general rule. But, you have to need that scale first!
> and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.
> BTW, monolith DB has its own form of eventual consistency. Process A puts data into DB, process B picks it up later and affects the DB. There's no reasonable way that everything in such a multi-use DB is always logically in agreement. You're just guaranteeing that B sees what A writes immediately, which comes at a cost
Transactions have existed for years, and DB execution engines have been able to concurrently handle non-dependent transactions since the mid 90's.
> It gives you a smaller blast radius when something goes wrong, avoids over-stressing a single DB, alleviates single points of human dependency like the DB curator, lets you scale separate pieces independently, and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.
Vertical scaling of Db's is a non issue. If your DB is complex, get a DBA...
Have you actually done any of this in production before? It doesn't seem like it honestly.
Then, you will not like microservices. Microservices make it harder, not easier, to organize data.
You have to worry about problems such as eventual consistency, and figure out how to join data across multiple data sources.
It compounds the problem significantly, and the only thing it gives you is that it forces you to silo data. That can be a good thing, but it doesn't solve the data organization problem.