Comment by vjvjvjvjghv
6 hours ago
"Big companies mostly seem to use the microservice(s) per team model. "
I am good with that. What we often see is 10 microservices per team of 3 devs. And ideally using the same database.
6 hours ago
"Big companies mostly seem to use the microservice(s) per team model. "
I am good with that. What we often see is 10 microservices per team of 3 devs. And ideally using the same database.
I've seen a startup with 10 devs + 60+ microservices and growing.
The team was stuck in a mindset that they just hadn't split things up enough to arrive at nirvana.
Been there before - I worked at a company where some geniuses thought that microservices would solve all of our scaling issues. We ended up with four microservices just to send an email (one to template, one to send, one to persist to database and one other which I can't remember now).
Multiple services using the same database will typically end poorly. When schemas or indexes change, how will that affect all of the different services? How do their read/write patterns differ? When one service needs to scale, will the additional connections starve the other services? And worse, if a service ends up moving to a different team or department, who controls the database?
I prefer a service that fronts the database. Swap the database, scale it, whatever, and clients keep going.
[dead]