Identify Design Options to Address ASRs

Design Options

This blog post is part of Steps to Design an Architecture. Once the ASRs are identified, next steps is to start the design. It may or may not be sequential process based on the project context the delivery methodology that is followed in a project.

To start the design, start with high priority ASRs to address most critical requirements first. To address one or more ASRs, a design option need to be identified for example, an architecture style needs to be identified first. It can be Layered, SOA, Microservices or any other based on the requirements.

An Architecture Style enables architecture design for some of the qualities such as maintainability, scalability, reliability etc. and set the direction for further design decision and limit the design options, suitable for the selected architecture style.

It is recommended to identify all the major design decisions with Rationale and Implications to address ASRs. An example of such log is as below,

Design Options Log

There could be multiple options, when we start for any design Area, for example Database or Storage. There can be different ways to identify a particular option,

  • SQL vs NO-SQL
  • Table vs Document vs Key-Value
  • Row vs Columnar

But, I generally start with CAP Theorem to help with decision making and then further drill down a type of data store.

Wiki – In theoretical computer science, the CAP theorem, also named Brewer’s theorem after computer scientist Eric Brewer, states that it is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees.

  • Consistency (C): Every read receives the most recent write or an error
  • Availability (A): Every request receives a (non-error) response, without the guarantee that it contains the most recent write
  • Partition tolerance (P): The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

From above Image, we can deduce below,

  • Most of the RDBMS support A & C but not P so can’t be deployed on multiple distributed partitions.
  • Most of the NO-SQL databases support P so we have to choose between A or C, but not both as per the requirements.

Using above guidance, we can identify some options for data store and then, further continue with the decision making.

Below are few books to learn about designing data intensive application…

Thank you and Happy Reading !

You May Also Like

%d bloggers like this: