CQRS using Redis MQ

Question

I have been working on a CQRS project (my first) for over the last 9 months which has been a heavy learning curve. I am currently using JOliver's excellent EventStore in my write model and using PostGresSql for my read model.

Both my read and write databases are on the same machine which means that when a change is made to the write database, in the same synchronous call a change is made to the read model.

As I was learning CQRS I felt this was the best way to go as I had no experience with message queue/service bus frameworks such as MassTransit, NServiceBus etc.

I am now at a point with most of my architecture in place to introduce a message queue framework.

Today, I came across Redis MQ which is part of ServiceStack and as we are already using ServiceStack for our Rest based HTTP clients, this seems like the right way to go.

My question is more about understanding what I need to know (or if I have any misunderstandings) to implement Redis MQ and whether Redis MQ is the right choice?

Now from what I understand, I would use Redis MQ as a durable queue between the write and read database. Once my event store has recorded that something has happened in my domain then it will publish to Redis MQ. The services listening for events/messages would receive the event/message from Redis MQ and once it has processed it (i.e. update or write to the read model), a notification/response goes back to the event store to tell the event store that the message has been received and processed by the listener/subscriber.

Does this sound correct?

Also would the Redis MQ architecture give me everything that NSB, RavenDB, MassTransit etc offer?

Also, I will be deploying to windows 2008 and 2003 server. Is Redis stable for these OSs?

Elisabeth

Answer 1

Now from what I understand, I would use Redis MQ as a durable queue between the write and read database.

Yes this is correct.

Once my event store has recorded that something has happened in my domain then it will publish to Redis MQ.

Yes and this can be done in several ways. It can either happen as part of the transaction which persists to the event store or you can have an out of band process which continuously publishes events from the event store.

a notification/response goes back to the event store to tell the event store that the message has been received and processed by the listener/subscriber.

The response back to the event publisher is usually omitted. This truly decouples the publishers from subscribers. You make the assumption that once the message is published, all interested subscribers will handle it. If something happens, an error should be logged.

Also would the Redis MQ architecture give me everything that NSB, RavenDB, MassTransit etc offer?

I don't have experience running Redis MQ, but I do know that Redis supports pub/sub which is one of the value propositions of NSB and MassTransit (as opposed to say bare-bones MSMQ). What MT and NSB offer beyond pub/sub are sagas and it doesn't seem like Redis MQ support those out of the box at least. You may not ever have a need for sagas so this should not automatically be a deterrent. RavenDB is not a message queue so it doesn't apply here.

Also, I will be deploying to windows 2008 and 2003 server. Is Redis stable for these OSs?

I've run Redis on 2008 R2 and it has been stable so I would think Redis MQ would be stable as well.

Luna

Thanks for all your help. I have to decide which durable messaging queue to use in my case, but I think I need to spend a few days still learning what is best. What would you suggest? :) – Elisabeth

What I've used most in production is NSB+MSMQ, but MT is equally capable, though lacking in docs. Make sure to look into licensing for NSB to see if it aligns. Redis MQ seems interesting, but can't comment. Overall, try a few different things to give you a better sense of how messaging is an infrastructural concern and shouldn't creep to much around in the rest of the app. – Luna

Thank you once again for your wisdom :). I have a some idea what NSB offers, I just need to see how Redis MQ does things like (retrying failed messages, how to view failed messages or view a message queue to see what messages have to be processed etc). I need to look at the NSB licensing, we don't have that many messaging going through and in addition at this stage the read and write databases are on the same machine. – Elisabeth

Answer 2

I think the ServiceStack implementation of message queueing in Redis is more appropriate for job-queue scenarios - it pushes a message onto the end of a Redis list and then uses Redis pub-sub to notify listening subscribers that there is a message to pull from the queue. Any consumers would be competing for messages.

For event sourcing, you may be more interested in a type of fanout or topic based messaging topology as offered by RabbitMQ, not that that precludes you from building that sort of thing using Redis data structures yourself.

Nixon

Thanks for the reply. In my case, I only have one subscriber which is my read model as I want to ensure the domain model(write) and the read model do not go out of sync. In this case, would RedisMQ be fine? – Elisabeth

Yep, the current RedisMQ implementation is perfect for your needs then. – Nixon

Answer 3

You may be interested in a little side project of mine on GitHub which is a queue and persistence implementation for NServiceBus using Redis. https://github.com/mackie1001/NServicebus.Redis

I'd not call it production ready and I want to port it to NSB 4 and do some thorough testing but the meat of it is done.

Juxtapose