1

While designing a complex system some of my colleges came back with the idea of having two separates APIs, one that will perform the writes into de databases and another one that will only do the reads.

I fail to deeply understand why separating those two concerns can be useful for the whole system. It can be useful when the system is for example suffering from heavy traffic when trying to read or viceversa but more than that...

Separating those to concerns also implies more complexity on the system since logic must be separated but in the other hand it can be useful when distributing and scaling the system, eg: having a read only database...

Any light into this darkness is more than welcome.

Thanks,

Javi.

Javier Rodriguez
  • 177
  • 1
  • 1
  • 4
  • Seems to me that you are talking about CQRS: Command Query Responsibility Segregation – Dherik Jan 15 '19 at 14:45
  • Possible duplicate of https://softwareengineering.stackexchange.com/questions/339359/isnt-cqrs-overengineering/339362 – Joeri Sebrechts Jan 15 '19 at 15:36
  • 1
    Possible duplicate of [Isn't CQRS overengineering?](https://softwareengineering.stackexchange.com/questions/339359/isnt-cqrs-overengineering) – Dherik Jan 15 '19 at 16:11

1 Answers1

2

I think one of the main reasons that this approach stems from the quagmire of object mapping. That link refers to relation DBs but it also applies to wire formats as well. In my experience, the hardest part of this is trying to build a two-way mapping. That is, trying to define both how you create objects from data and create data from objects. It's much easier to deal with each direction independently. There are, of course, a ton of drawbacks to this as well.

The situation where this really wins is when the usage patterns of how you input data into the system require a different representation of the data than what you need when you use that data.

A simple example: Let's say you capture incremental changes in weather from various systems. You then take those changes and create aggregates over periods of time and that's what you supply to your users. The representation of these is very different and there is very little benefit to trying to build both as a unified API. Mainly putting them together mainly creates needless challenges. By splitting them, you simplify things greatly.

JimmyJames
  • 24,682
  • 2
  • 50
  • 92