4 ms·

The biggest drawback I've seen to CQRS - particularly in an event driven architecture - has been increased complexity, usually in exchange for increased scalabi

by Sodman 6y ago

The biggest drawback I've seen to CQRS - particularly in an event driven architecture - has been increased complexity, usually in exchange for increased scalability. I'm a big fan of "Do the simplest thing that could possibly work" so I'm mostly opposed to CQRS except for some niche cases. A CRUD design for an app can scale well enough for most businesses to get into very decent revenue numbers. When you start bumping up against limitations, then you can start to refactor. Until then, the simplicity of a CRUD app can let you prototype and ship faster, as well as significantly boost new dev onboarding time.

whalesalad 6y ago
Well... you’ve just described the law of nothing in life is free. Of course there are trade offs with any architecture choice.
AndrewSChapman 6y ago
Agree 100%. There are probably better alternatives if you're needing to improve scalability.
kemiller2002 6y ago
It is amazing how much a well tuned and properly functioning database can handle. At my last job, this was a huge hurdle I was tasked with handling. They're CQRSish design slowed so many things down through needless complication or hidden inefficiencies. People always jump to "we need to scale and this will make it faster" when the real answer is often, "how about we focus on some fundamentals and just make our code more efficient"
barumi 6y ago
> The biggest drawback I've seen to CQRS - particularly in an event driven architecture - has been increased complexity, usually in exchange for increased scalability. I fail to see how CQRS is a factor in increased complexity. After all, CQRS boils down to separating the interfaces for queries/reads/immutable operations and commands/writes/mutable operations. Unless you're bolting on unrelated concepts, like event sourcing, then CQRS is not a significant source of increased complexity in non-trivial applications. Can you shine some light on which aspects led to higher complexity in your use of CQRS?
- unklefolk 6y ago
  One obvious drawback is the amount of boilerplate code and multiple files. Although the essence may be no more complex, the amount of "noise" and fragmentation across files can increase the mental load.
- hn_throwaway_99 6y ago
  I think the issue really is that when people talk about CQRS they are almost always talking about event sourcing + CQRS, and that's where the complexity lies. I mean, look at GraphQL, which essentially makes it trivial to implement "plain" CQRS because there are always explicitly separate operations for mutations and queries, and it's easy to have separate object definitions for these operations (this is in direct contrast to many REST architectures, where your verbs - GET, PUT, POST, DELETE, etc. - are fundamentally operating on the same objects). However, underlying in the actual DB there is just a single representation. But I think when people talk about CQRS these days they are really talking about the underlying data being different (e.g. a log of write operations vs a repository of queryable objects), and that usually implies something like event sourcing, and with that model you have a ton of complexity involved in keeping the different "sides" in sync, and since many update operations also involve queries (i.e. only do this update if something else is true about another object) you get into transactional difficulties as well.
  - Sodman 6y ago
    Correct, this is what I meant. Even though they're technically different concepts, I've found in practice they're almost always coupled together. FWIW, these days I usually do go with GraphQL over REST in my APIs, partially due to some of the advantages you get from separating the queries and mutations. But like you said, I prefer to ultimately store the info in a DB in one consistent format unless it's absolutely unavoidable. Sometimes it is unavoidable, but like the article mentions you can frequently get away with having a "Reporting Database" separate to your "Primary data" database. Once you start spreading your data across multiple databases and storing it in different structures managed by different apps with different APIs, suddenly getting to even eventual consistency can quickly become a non-trivial problem, which itself is usually solved or mitigated by adding more complexity. Sometimes this complexity really is required because of incredibly large scale, large/numerous engineering teams working on one project, or unique business requirements - but my original point was that for most cases, particularly new products/projects that aren't going to have 10M+ daily users from launch, you should keep it simple until you know for a fact that it needs the complexity of a full CQRS + event sourcing system.

by Sodman 6y ago

whalesalad 6y ago

Well... you’ve just described the law of nothing in life is free. Of course there are trade offs with any architecture choice.

AndrewSChapman 6y ago

Agree 100%. There are probably better alternatives if you're needing to improve scalability.

kemiller2002 6y ago

It is amazing how much a well tuned and properly functioning database can handle. At my last job, this was a huge hurdle I was tasked with handling. They're CQRSish design slowed so many things down through needless complication or hidden inefficiencies. People always jump to "we need to scale and this will make it faster" when the real answer is often, "how about we focus on some fundamentals and just make our code more efficient"

barumi 6y ago

> The biggest drawback I've seen to CQRS - particularly in an event driven architecture - has been increased complexity, usually in exchange for increased scalability. I fail to see how CQRS is a factor in increased complexity. After all, CQRS boils down to separating the interfaces for queries/reads/immutable operations and commands/writes/mutable operations. Unless you're bolting on unrelated concepts, like event sourcing, then CQRS is not a significant source of increased complexity in non-trivial applications. Can you shine some light on which aspects led to higher complexity in your use of CQRS?

unklefolk 6y ago
One obvious drawback is the amount of boilerplate code and multiple files. Although the essence may be no more complex, the amount of "noise" and fragmentation across files can increase the mental load.
hn_throwaway_99 6y ago
I think the issue really is that when people talk about CQRS they are almost always talking about event sourcing + CQRS, and that's where the complexity lies. I mean, look at GraphQL, which essentially makes it trivial to implement "plain" CQRS because there are always explicitly separate operations for mutations and queries, and it's easy to have separate object definitions for these operations (this is in direct contrast to many REST architectures, where your verbs - GET, PUT, POST, DELETE, etc. - are fundamentally operating on the same objects). However, underlying in the actual DB there is just a single representation. But I think when people talk about CQRS these days they are really talking about the underlying data being different (e.g. a log of write operations vs a repository of queryable objects), and that usually implies something like event sourcing, and with that model you have a ton of complexity involved in keeping the different "sides" in sync, and since many update operations also involve queries (i.e. only do this update if something else is true about another object) you get into transactional difficulties as well.
- Sodman 6y ago
  Correct, this is what I meant. Even though they're technically different concepts, I've found in practice they're almost always coupled together. FWIW, these days I usually do go with GraphQL over REST in my APIs, partially due to some of the advantages you get from separating the queries and mutations. But like you said, I prefer to ultimately store the info in a DB in one consistent format unless it's absolutely unavoidable. Sometimes it is unavoidable, but like the article mentions you can frequently get away with having a "Reporting Database" separate to your "Primary data" database. Once you start spreading your data across multiple databases and storing it in different structures managed by different apps with different APIs, suddenly getting to even eventual consistency can quickly become a non-trivial problem, which itself is usually solved or mitigated by adding more complexity. Sometimes this complexity really is required because of incredibly large scale, large/numerous engineering teams working on one project, or unique business requirements - but my original point was that for most cases, particularly new products/projects that aren't going to have 10M+ daily users from launch, you should keep it simple until you know for a fact that it needs the complexity of a full CQRS + event sourcing system.