I have a microservices architecture with event-sourcing and CQRS. So my commands are already separated from the query part. The problem lies in syncing the query and quering it, not the command part.
Every few minutes about 60,000 commands are sent and stored as events using event-sourcing
pattern. Via CQRS the actual data (not the event) is synced to another service which stores it in a database. meanwhile the data is read only a dozen times every few minutes.
In other words. This one service receives 60,000 write operations but only a dozen read operations.
I would really like to adhere to the design patterns of microservices, aka one database per service
but for scaling reasons I don't see that feasible in my scenario. Writing to the database needs to significantly scale more than reading the database.
I saw a similar question but the answer proposes to use CQRS, which I already have implemented. Somebody told me before to remove the event-sourcing but that still leaves me with 60,000 writes and 10 reads.
What should be my architecture for scaling the reads and writes independently? I'm thinking of creating two separate services but this would be against the one database per service
pattern.
Aucun commentaire:
Enregistrer un commentaire