Thoughts on CQRS vs CRUD for these services

[dudash]

I want to document decisions made in the architecture and provide a spot to debate - thus this issue.

CRUD was a simple v1 choice because it's easy to implement but as we grow some services might be better served by a CQRS model. I'm hesitant initially because of the added complexity. There are no plans to add eventing (KNative) into this demo repo.

Microservices.io Pattern ref Martin Fowler link

[dudash]

@gbengataylor this might be a good Q for you. I know you've been thinking about this a lot recently...

[gbengataylor]

I think as we start to expand on some of the features CQRS may be beneficial if there is a need to decouple reads from writes. For e.g, the search service - the "write" api for search may be different from the "read" (the read may need to return denormalized or aggregated data). Rather than doing the transformation on the read, it may make sense to have separate data representations for each operation challenges

• is the read data just a database view of the write ?
• is the read data a separate table or in a completely separate database type?
• if physically segregating reads from writes, the write data needs to be projected. This isn't trivial as you want to avoid multiple applications of the same projection. A tool like https://debezium.io/ could help