Search code examples
.netdatabasearchitecturecqrs

Is CQRS still helpful when your read and writes have similar scaling requirements?


I have a .NET MVC ecommerce basket application which tracks the items customers have placed in their basket. We use the repository pattern to read/write items to the basket table, and at times this app comes under significant pressure from users, with the SQL database suffering as a result.

I wondered whether making use of CQRS could help, but in this situation the number of reads/writes to the basket is very high in both cases. Also (unless I'm misunderstood), it feels like Eventual Consistency wouldn't be very appropriate here, because updates to the basket need to be readable immediately so that users can track and see what they've added. A second's worth of delay would cause mass confusion.

Is this a scenario which is simply unsuitable for CQRS? Would it be better to focus on just horizontally scaling the app and database (by splitting customers into different groups perhaps), or are there other architecture styles which could help?


Solution

  • Just for clarity: CQRS read sides don't have to be eventually consistent. In SQL, it's quite easy actually to have a consistent read model: just create the it in the same transaction as the write operation. Or even use materialized views. CQRS only means keeping a separate model in code and data store for writes and reads, and does not naturally imply eventual (or any other) consistency model.

    For your exact usecase, I don't really see why a basket would benefit from a separate read model (it might even make it worse), but I don't know your full spec. If you index your data correctly, reads should not have to be a problem. I would go in another direction to optimize write performance, optimizing the schema might help.

    Also, if the basket is something that is not critical to be durable, you can consider using a memcache (redis for example) only to store the basket. What is the worst-case scenario/business impact that would happen if redis fails (should be pretty rare anyways), and all baskets are dropped, compared to the perfromance benefits? I think a slow system hurts more than a possible impact of a failure that might happen once-or-twice a year (or never).