System Architect Serious: CQRS pattern

In a simple sentence: the command query responsibility segregation (CQRS) split the write and read actions in a system.

CQRS patter (from Amazon article)

If you want to know how to implement them in AWS or Azure, please refer to follow to articles:
https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/cqrs-pattern.html
https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs

From system architect perspective, where is the possible pain points of this pattern. The key is step 4, how to ensure the data consistency between the two databases! What’s the choice of the two databases? You can possibly have four combination: SQL & SQL (the classical way), SQL & NoSQL (a popular choice), NoSQL & NoSQL (a straightforward solution) and NoSQL & SQL (not easy). Do you need Strong Consistency or Eventual Consistency is acceptable ? What’s the maximum lagging in your design?

Tell me if you have any though?

Build a Basic Web Application in AWS within 30 mins

Want to test your knowledge about the AWS as a solution architect ? This might be a good hands-on task to see how fast you can set up this web application: https://aws.amazon.com/getting-started/hands-on/build-web-app-s3-lambda-api-gateway-dynamodb/

NoSQL Design Principle

NoSQL design requires a different mindset than RDBMS design. For an RDBMS, you can go ahead and create a normalized data model without thinking about access patterns. You can then extend it later when new questions and query requirements arise. You can organize each type of data into its own table.

• By contrast, you shouldn’t start designing your schema for NoSQL until you know the questions it will need to answer. Understanding the business problems and the application use cases up front is essential.
• You should maintain as few tables as possible in a NoSQL application. Having fewer tables keeps things more scalable, requires less permissions management, and reduces overhead for your application. It can also help keep backup costs lower overall.

So we normally start design RDBMS by drawing the Entity-Relation diagram. This can support various flexible queries without significant change the data model.

In NOSQL, we need to optimize specific queries for high performance and availability. What’s the business queries or access patterns:

My experience is to start from RDBMS first then switch to NoSQL when it is needed. If you plan to migrate existing data storage solution, make sure to evaluate different NoSQL solutions first.

• RDBMS
  • SQL
  • Oracle
• NoSQL
  • Key-Value
    • Dynamo
  • Column Family
    • HBase
    • Cassandra
    • Big Table
  • Document Oriented
    • MongoDB

Reference: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html

DynamoDB Time to Live (TTL)

Store a client side session is very common in client server architecture. Another example is in a hotel booking system. You want to maintain a booking time window like 10 mins. To implement this, it is quite simple in AWS DynamoDB.

Create a table with following fields: the partition key (UserName) and the sort key (SessionId). Additional attributes like CreationTime, and ExpirationTime track the session information. The ExpirationTime attribute will be set as the TTL attribute on the table later.

The TTL attribute must:
– The item must contain the attribute specified when TTL was enabled on the table.
– The TTL attribute’s value must be a top-level Number data type.
– The TTL attribute’s value must be a timestamp in Unix epoch time format in seconds.
– The TTL attribute value must be a date timestamp with an expiration of no more than five years in the past.

Enable the TTL on the table: click the table, under the “Additional settings”:

You can find the delete event under the Monitor or CloudWatch.