Do we need a mix of synchronous and asynchronous command handlers in CQRS?

Question

1. A user registers on our site and gets logged in. A RegsiterUserCommand is sent to an asynchronous command handler.
2. The user wants to change their address but the RegisterUserCommand has not been processed yet. There is no user record in the system.

Is this a case for synchronous command handlers? A user record would be created prior to authenticating the user. Or should I rethink the requirement to authentic users after registration? Users won’t be able to gain access to the site until their account has been created. If users don’t gain access to the system straightaway there may be drop off in usage.

Is it common to see a mix of synchronous and asynchronous command handlers in a CQRS system?

Answer 1

I have everything running in async. To keep everything simple, queues are FIFO; plus there is one processing thread per partition. This way commands are always processed in the order of sending. Plus we still have the scalability, since thread per partition could be simply turned into machine per partition without the need to repartition the entire solution.

There are a few cases, where we might want synchronous processing (in my case example would be initial user registration, since we need to validate a few things on the server before letting him to go on). In this case after the command is send, user is shown the "please wait for a few seconds, while your registration is processed". As soon as the registration is confirmed (or failed), user is automatically taken to the next screen. This is trivial to do with AJAX in web UI. Desktop UIs are even simpler.