You are currently viewing System Design Overview-Part 2
system design with database

System Design Overview-Part 2

Loading

Introduction

This short but small blog is about two points which are discussing database and where to choose which and another is use case of application program at front end and backend. Before reading this blog it would be great to read the previous blog on system design series which is as below

system design overview | aisangam

Table of Content

How to choose database for your application

Choosing Relational Database under what circumstances

Properties of relational database

  • Schema
  • ACID

Schema: When your business has some specific schema and you have constraints for that scheme then go for relational database

ACID Property of Relational database

  1. Atomicity: Means does not break . For example either the transaction should happen or not. 
  2. Consistent: Giving same value to x request. This does not mean that one request takes place in x time from the database and another request takes place in y time from the database. 
  3. Isolation: Different operations should not know each other. For example if read and write is happening to the database both operations should happen in an isolated way.
  4. Durability: Logs are ensured and stored in the persistent disks.

If you think that your business comes under ACID property go for Relational Database

Where Relational Database is not used

  • If the schema is not fixed
  • Application is going to scale 

This does not mean that flexible schema and scaling is not supported by relational db but their performance decreases with these.

Choosing NOSQL Database under what circumstances

  • KV Stores (Key Value): Like you do not have a fixed scheme and want to integrate new keys when required. For example you are building something and you need to integrate discount as a new key. Catching solutions are implemented using key value stores.  Examples are reddis, memcached and DynamoDB. Quite fast and provide quick access. Most of the data is in memory. Request Response can also be stored in the key value.
  • Document based: When you are not sure about the scheme and how the fields evolve over time. They support heavy read and write. They have collections( like tables) and documents (like rows). The downside is that it does not provide the acid transactions. 
  • Column DB: Midway of Relational and Document based. Fixed Schema but do not support ACID transactions. Used for heavy writes and special reads. Like event data i.e choosing database for music app. Example: Cassandra, HBase.
  • SearchDatabase: Like elastic search.

Role of application program at front end and back end

Front end application: These are there on the client side. For example when you interact with the application either on the web or desktop these applications are deployed there which are responsible for a certain set of tasks. Like you are using instagram on the web, these applications may help you to login, post the picture.

Backend applications: Now imagine when you login your details need to be stored somewhere. When you need to post functionality is to develop to help you post or all your post details need to be stored. This is implemented using a backend application.  

Application means a set of responsibilities executed at any layer.These are pieces of code which are written in some languages. 

For frontend like for web javascript is used, for ios swift is used. For backend python, java, Go. One can use languages for both frontend and backend  or frameworks. Choice is yours but writing everything in language is more complicated and using frameworks makes the work easy.

Applications can be monolithic or micro services depending on the scale of the work. To make an effective end to end system, it is very important to understand the requirements very carefully. 

Conclusion

In this blog some insights were drawn on how to choose the database for your application as well as how to choose application program for the front end and back end. Also in the introduction, link is added to the previous blog which is overview of the system design. This is the part 2 of the system design series, I would also like to show you AI You Tube Channel where emerging and trending videos on data science are uploaded from time to time.  Also would like to introduce our child branch named as selfawareness for technical topics

Check you tube video for this blog from below

Leave a Reply