I am going to try to build a implementation of CQRS and ES for large scale application (1M users) authentication API. Below is my initial architecture draft (Ignore Azure related stuff). I am going to do this approach because I see the following advantages:

  1. Even if the event store is down, the login system can still function (vice versa).
  2. Since we’re going to use materialized views:
    • Lock contention is lower
    • Read / Write operations have higher throughput

However, I am still undecided if using a SQL Database is or NoSQL for my materialized views. Please let me know about your thoughts and I would appreciate it very well.

enter image description here

  • 1
    In order to make the decision, you have to identify your non-functional requirements, and then determine which type of database best meets those requirements. You've provided a couple of vague criteria (low lock contention, high throughput), but it is unclear from your question whether your database choice will even matter, given those two criteria. 1M users probably sounds like a lot to you, but it's almost certainly not 1M simultaneous users. Rule of thumb: use a SQL database unless you really need the special features that an extremely large Key/Value store provides. – Robert Harvey Jan 7 '18 at 3:08
  • Thanks for the notes @RobertHarvey, will keep it in mind. I am just performing this coding exercise so I can acquire the hows of large scale applications. I want to avoid the locks that might be produced out of the materialized view bro!. – Allan Chua Jan 7 '18 at 6:43

This is a hard question because both types of persistence have advantages and disadvantages. But, since we are taking about a CQRS Read model (I will use this term for Materialized view) (assuming that the authentication operation is done read-only, i.e. by a query) we could think about the following considerations:

  • for each type of supported authentication scheme you could have a different implementation; i.e. username/password using NoSQL and one-time-login-by-email-link using SQL

  • some authentication schemes like username/password are easy to implement; you could implement it for both persistent types and use benchmarks or A/B testing to decide which one to use; this is simple to do thanks to CQRS and Event sourcing by subscribing both Read modes to the relevant domain events

  • both have solutions for availability: SQL and NoSQL have some kind of replication solutions (master/slave or replica sets) but thanks to CQRS you are not forced to use the built-in replication; you could just have multiple instances of the same Read model running on different nodes; here depends more on the operational costs

  • both have solutions for horizontal scalability, like sharding; but again, thanks to CQRS you could implement sharding yourself by creating a table/collection for each region or country or whatever dimension makes more sense; or you could combine the built-in sharding with this technique

  • NoSQL makes it easier to store/retrieve the entities but if the Read model is simple (i.e. user ID, username and hashed password) SQL works too

So, it depends on each authentication scheme that you will support, on how much code you will write, on the operational costs of replication/sharding etc.

| improve this answer | |
  • How is the authentication mechanism a deciding factor? – Robert Harvey Jan 7 '18 at 3:10
  • @RobertHarvey because every auth type has a different model – Constantin Galbenu Jan 7 '18 at 3:11
  • @RobertHarvey so, one can have a different implementation for each model – Constantin Galbenu Jan 7 '18 at 3:15
  • But how does that help you decide which database to use? – Robert Harvey Jan 7 '18 at 3:18
  • @RobertHarvey it helps in the sense that you don't need to choose a single solution that fits all the auth schemes and one has the posibility of varying the persistence type depending on the auth scheme. In other words you could use both RDMS types at the same type but for different auth schemes. – Constantin Galbenu Jan 7 '18 at 3:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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