System Design Preparation

Follow this order for design interview prep:

 Connect to Arslan Ahmad on linked in, lot of good quick cheet sheets you get from Arslan on some design concepts.

CAP: https://www.interviewbit.com/system-design-interview-questions/#cap-theorem

SQLVs No-SQL:  https://www.interviewbit.com/blog/sql-vs-nosql/

 Kafka: http://cloudurable.com/blog/what-is-kafka/index.html

Kafka Vs RabbitMQ: https://dattell.com/data-architecture-blog/kafka-vs-rabbitmq-how-to-choose-an-open-source-message-broker/

 
Redis Vs MemcacheD : http://crackquery.blogspot.com/2024/10/memcached-vs-redis.html
Sharding disadvantages: https://thinkscholar.com/programming/database-concepts/disadvantages-of-sharding/ 

 CodeKarle Designs: https://github.com/codekarle/system-design/tree/master/system-design-prep-material/architecture-diagrams

 

AWS Services for 3Tier Arch : https://www.youtube.com/watch?v=FDEpdNdFglI

Paid Courses:

 https://www.designgurus.io/course-play/grokking-the-system-design-interview?doc=638c0b5dac93e7ae59a1af6b

 https://www.designgurus.io/course/grokking-the-advanced-system-design-interview

 https://www.designgurus.io/course-play/grokking-the-system-design-interview?doc=638c0b5dac93e7ae59a1af6b


 

 

Cache:

While considering using/building a cache for your systems, you need to consider

Use of Cahce - Cache is mainly used to reduce the latency by avoiding DB calls and long network calls.  Plan to use cache for static data or pre-computed data.

Data Eviction - You should choose appropriate eviction policy for your cache to have place for new objects, else you will not benefit from cahce use and sometimes it causes more damage

    LRU - Least recently used data should be evicted from cache

    LFU - Least frequently used object, even though very recently accessed will be evicted from cache

    FIFO - The object that is first added to cache will be deleted first to add new  objects

Consistency - Your cache and DB should always be in consistent and to achieve you can use following mechanisms.

    Write through Cache - Update cache when you update the DB in a single call

     Read Through Cache - Update cache when you have cache miss 

     Write Around - Write to Cache when you write to DB in async call

Where to place cache:

  Close to the Application : 

        Good for small in memory data , avoid n/w calls.  Read through is best way of maintaining cache consistency

  Close to the DB:

       Keep cache outside of application layer and maintain common/global data in cache. This is reposible for updating the cache when DB is out- of sync. Support host failures as new hosts need not warm up cache.

Commonly used distributed Caches:

Elastic Cache from AWS,  MemcacheD , Redis

No comments:

Post a Comment

AWS Data Pipeline Services

https://www.youtube.com/watch?v=tykcCf-Zz1M