Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working on an app which I would dearly love to transition from a fairly traditional layered architecture to CQRS, for a number of reasons, not least fo which is that having a robust event log will make adding a couple of feature requests I can see barrelling towards me trivial to accomodate.

Now, I have a conceptual problem: of around 40 commands the user can initiate, there are three which the user needs to be sure have successfully completed before the UI lets them do anything else. Everything else fits into the "submit a request, query for success later" model, except for these three commands.

How is this handled in CQRS-land? Do I separate the three blocking commands to effectively a third service, so I have Commands, Queries, and BlockingCommands? Do I have a two-stage event processor with an in-request blocking first stage which only gets used for the blocking commands? Does the existence of these three commands mean that the whole idea of applying CQRS is invalid? Should I just pretend they aren't blocking and poll for success in the UI?

I'm sure this must come up on other projects, how is it usually handled?

share|improve this question

No one ever said that all, or any for that matter, commands must be asynchrounous. The core concept is to separate reads and writes. When you use commands and events as the the transport mechanism, making them async is definitely easier.

Process these synchronously.

share|improve this answer

it's easier to make an asynchronous operation seem synchronous, rather than the other way round.

you could use REST, and the UI, so that you provide a modal dialog, and provide a callback / poll for success. This would effectively allow you to have a mechanism for making it seem synchronous and modal.

It sounds though like you have a scenario that would benefit from a saga. Check out what Udi ( ) and Greg Young ( skills matter ) have to say about this.

share|improve this answer
You have a point about the saga. Maybe I should rethink this. – regularfry Jul 1 '11 at 8:34
thanks :). I would have said more about implementing a saga, but I wasn't clear on exactly the scenario you were describing, so thought it better that you 'go to the source' :) ( the last day of Greg's lectures pretty much cover what you need, so try looking for some of his newer talks/posts ) - Udi, has loads of resources about sagas. – James Jul 1 '11 at 10:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.