24 ms·

Yes, shared database is an anti-pattern in micro services architecture. If one shared database can serve your system well then you don't need microservices. Yo

Yes, shared database is an anti-pattern in micro services architecture. If one shared database can serve your system well then you don't need microservices. You should build a monolith instead. The main reason for using microservices is scale. First ability to scale development teams and secondly ability to scale the infrastructure. With microservices you get vertical sharding out of the box. Yes it means dealing with eventual consistency for at least a few usecases. But any system that wants to serve millions of concurrent users needs to deal with eventual consistency as some sort of vertical or horizontal sharding is necessary at that scale anyways.

dehrmann 8y ago
> The main reason for using microservices is scale What enables this scale is the encapsulation you get with microservices. You lose this with a shared database. You get a similar problem with multitenancy because "isolated" microservices are impacted by what unrelated services do, so there's a loss of resiliency.
eweise 8y ago
The issue isn't about microservices, its about isolating dependencies between various components of the system. When any part of the system can reach into the user table then you've created a big ball of mud. Even with a monolith, you should have a defined contract between the user service and the rest of the system. That way you can start with a monolith and move to microservices later as needed. You can also change the underlying persistence layer without disrupting the rest of the system. You could for instance start with mongodb for user information while other system components use postgres. If sometime later you think postgres handle json just as well, no problem switch user over to postgres and the rest of the system is unaffected. You should really build your monolith in a similar fashion to microservices, just leave out the remoting layer.
- ebiester 8y ago
  For Insert/update/delete, that makes sense. However, many times it makes sense to just do the join in the database rather than make an n^2 join in user space. This becomes problematic in collection cases - 100 cases belonging to 70 users. It's a quick left hand join but a slowdown in application space.
  - eweise 8y ago
    I don't disagree but I think in practice you're probably dealing with a single user at a time when working with orders. A query that referenced n users plus their orders is probably a reporting type query that could be supported in a data warehouse where all the tables could be joined together.
    - badestrand 8y ago
      > query that referenced n users plus their orders is probably a reporting type query No, there are enough other valid cases, e.g. display last customers and their orders or some simple "others have also bought". In practice you will need to join a lot spontaniously and can not just defer that to a data warehouse.
      - scarejunba 8y ago
        Most stores of large scale do not run online calculation or modeling for “others also bought”. It’s usually offline.
    - zaarn 8y ago
      "Show content your friends liked" is an easy example where you want an in database join, in userspace this operation would be incredibly slow.
  - ddebernardy 8y ago
    In Postgres you can use a foreign data wrapper to do such a join with a wide number of 3rd party data sources. https://wiki.postgresql.org/wiki/Foreign_data_wrappers https://wiki.postgresql.org/wiki/Foreign_data_wrappers
zepolen 8y ago
> First ability to scale development teams Except the scaling breaks down because suddenly everyone is bound by tight apis making change very very hard. The potential for services written in entirely different languages makes reallocating dev power less efficient. > Secondly ability to scale the infrastructure Anyone who's run a bunch of microservices in production will tell you this is a lie, it becomes a constant whack the bottleneck microservice mole. Not to mention the operational overheads of managing multiple microservices. > Yes it means dealing with eventual consistency for at least a few usecases > With microservices you get vertical sharding out of the box Wtf...
ec109685 8y ago
How many services actually have millions of concurrent users? That’s 100k req sec or so, which is a crapton.
- docker_up 8y ago
  Most companies don't need microservices. But the largest ones that are global definitely do.
- zaarn 8y ago
  Probably less than 1% of corporations deploying microservices actually have a load that justifies microservices.
FrankyHollywood 8y ago
"If one shared database can serve your system well then you don't need microservices". Exactly, nobody is even thinking about it anymore because "Twitter has microservices, Netflix uses MSA". Microservice architecture comes with a cost, like more complex deployment strategy (there are more dependencies) and overhead in transaction management, not to mention debugging a problem which hits multiple domains/services.

dehrmann 8y ago

> The main reason for using microservices is scale What enables this scale is the encapsulation you get with microservices. You lose this with a shared database. You get a similar problem with multitenancy because "isolated" microservices are impacted by what unrelated services do, so there's a loss of resiliency.

eweise 8y ago

The issue isn't about microservices, its about isolating dependencies between various components of the system. When any part of the system can reach into the user table then you've created a big ball of mud. Even with a monolith, you should have a defined contract between the user service and the rest of the system. That way you can start with a monolith and move to microservices later as needed. You can also change the underlying persistence layer without disrupting the rest of the system. You could for instance start with mongodb for user information while other system components use postgres. If sometime later you think postgres handle json just as well, no problem switch user over to postgres and the rest of the system is unaffected. You should really build your monolith in a similar fashion to microservices, just leave out the remoting layer.

ebiester 8y ago
For Insert/update/delete, that makes sense. However, many times it makes sense to just do the join in the database rather than make an n^2 join in user space. This becomes problematic in collection cases - 100 cases belonging to 70 users. It's a quick left hand join but a slowdown in application space.
- eweise 8y ago
  I don't disagree but I think in practice you're probably dealing with a single user at a time when working with orders. A query that referenced n users plus their orders is probably a reporting type query that could be supported in a data warehouse where all the tables could be joined together.
  - badestrand 8y ago
    > query that referenced n users plus their orders is probably a reporting type query No, there are enough other valid cases, e.g. display last customers and their orders or some simple "others have also bought". In practice you will need to join a lot spontaniously and can not just defer that to a data warehouse.
    - scarejunba 8y ago
      Most stores of large scale do not run online calculation or modeling for “others also bought”. It’s usually offline.
  - zaarn 8y ago
    "Show content your friends liked" is an easy example where you want an in database join, in userspace this operation would be incredibly slow.
- ddebernardy 8y ago
  In Postgres you can use a foreign data wrapper to do such a join with a wide number of 3rd party data sources. https://wiki.postgresql.org/wiki/Foreign_data_wrappers https://wiki.postgresql.org/wiki/Foreign_data_wrappers

zepolen 8y ago

> First ability to scale development teams Except the scaling breaks down because suddenly everyone is bound by tight apis making change very very hard. The potential for services written in entirely different languages makes reallocating dev power less efficient. > Secondly ability to scale the infrastructure Anyone who's run a bunch of microservices in production will tell you this is a lie, it becomes a constant whack the bottleneck microservice mole. Not to mention the operational overheads of managing multiple microservices. > Yes it means dealing with eventual consistency for at least a few usecases > With microservices you get vertical sharding out of the box Wtf...

ec109685 8y ago

How many services actually have millions of concurrent users? That’s 100k req sec or so, which is a crapton.

docker_up 8y ago
Most companies don't need microservices. But the largest ones that are global definitely do.
zaarn 8y ago
Probably less than 1% of corporations deploying microservices actually have a load that justifies microservices.

FrankyHollywood 8y ago

"If one shared database can serve your system well then you don't need microservices". Exactly, nobody is even thinking about it anymore because "Twitter has microservices, Netflix uses MSA". Microservice architecture comes with a cost, like more complex deployment strategy (there are more dependencies) and overhead in transaction management, not to mention debugging a problem which hits multiple domains/services.