In a service-oriented architecture, is the database decentralized?

5

I'm looking forward to getting a great project, and on its own scale I've suggested adopting a service-oriented architecture - because it is easier to solve several average problems than a very large one. I was asked about the database: that even if the application is divided into modular components, the bank should be designed a priori . This sounded strange to me, but from my lack of experience with this paradigm I could not argue about it.

It is my understanding that each service should be tightly coupled ( loosely coupled ) to justify this approach. And my common sense says that - if it's not docked - it does not have to be on the same bank, even though it makes it easier to grow in scale (putting each subsystem on a different server, for example). This implies, of course, to lose some of the referential integrity - because in the few points where one subsystem interacts with another, we have entities in common between them. In my opinion, this is not a big problem, but this is the main concern of those who questioned me, insisting that only with a unified database can the data consistency be maintained.

Which of these two approaches is most common in systems that follow SOA? Because? And how the problem is resolved:

  • of the data consistency, if the response is "distributed"?
  • of modularization / growth in scale, if the answer is "centralized"?
asked by anonymous 22.08.2014 / 23:13

1 answer

4

Ideally, the bank should be abstracted.

I am assuming a case in which the "bank" holds a mass of data that pertains to and relates exclusively to the system covering the services themselves. Whether it is centralized or not, all services that access it must do so through the same endpoints / URIs. For them it should be transparent (ie, it should be irrelevant) whether the bank is centralized or decentralized. This also reduces the coupling because it makes it easier to replace one database with another.

Now, if you talk about distribution by giving a completely separate database for each service ... This is worth it if each service runs on a different domain (concept / system domain, not URL). This is common when you integrate your system with third-party systems. For example, if you want to make an application that says where your friends are, there's no problem (conceptual) in using the Facebook base for friends and the Google base for maps.

    
22.08.2014 / 23:30