One DB per service means one logical service. One logical service might run many copies (if stateless) or shards (if stateful/actors) of the same service for scale or availability. Likewise the DB means one logical DB which can be scaled with shards or replicas.
It is not exactly clear where CQRS fits... whether the Command and Query sides are just parts of the same logical service. Or whether they are different logical services. I think you could make a case and implement it either way. In our latest venture, we could probably consider them separate services with their own individual scaling knobs, since they do use separate databases, and a backend service translates from the command-side database (an event store in this case) to the query-side.
It really all depends on what you need for your use case.
Interesting point on the logical service Kasey. So one logical service could well be a combination of two separate read/write services?
In the use case, I have in mind, it sounds the same as yours. Having two different scaling knobs for reading vs writing is extremely useful. The volume of reading data is MUCH higher than the written data.
So a separate service handling that seems exactly right.
In most services I've written prior to this, I've still kept a clear distinction between C and Q. But rather than having completely different knobs, they run under one knob.
Interesting comments though, thanks for your input.
So one logical service could well be a combination of two separate read/write services?
Sure, if we are talking about stateless services. The database is probably going to require scaling before the compute resources do. When you do need to scale compute due to read load, it probably doesn't cost that much memory to also carry command handling code along for the ride even if it is mostly dormant. And you still retain the option to split the command and query sides off into different services if the need arises.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One DB per service means one logical service. One logical service might run many copies (if stateless) or shards (if stateful/actors) of the same service for scale or availability. Likewise the DB means one logical DB which can be scaled with shards or replicas.
It is not exactly clear where CQRS fits... whether the Command and Query sides are just parts of the same logical service. Or whether they are different logical services. I think you could make a case and implement it either way. In our latest venture, we could probably consider them separate services with their own individual scaling knobs, since they do use separate databases, and a backend service translates from the command-side database (an event store in this case) to the query-side.
It really all depends on what you need for your use case.
Interesting point on the logical service Kasey. So one logical service could well be a combination of two separate read/write services?
In the use case, I have in mind, it sounds the same as yours. Having two different scaling knobs for reading vs writing is extremely useful. The volume of reading data is MUCH higher than the written data.
So a separate service handling that seems exactly right.
In most services I've written prior to this, I've still kept a clear distinction between C and Q. But rather than having completely different knobs, they run under one knob.
Interesting comments though, thanks for your input.
Sure, if we are talking about stateless services. The database is probably going to require scaling before the compute resources do. When you do need to scale compute due to read load, it probably doesn't cost that much memory to also carry command handling code along for the ride even if it is mostly dormant. And you still retain the option to split the command and query sides off into different services if the need arises.