System Design Cheat Sheet

  



  1. System Design Interviews
  2. System Design Interview Cheat Sheet
  3. System Design Cheat Sheet Excel

Scale of the system such as requests per second, requests types, data written per second, data read per second) Special system requirements such as multi-threading, read or write oriented. High level architecture design (Abstract design) Sketch the important components and connections between them, but don't go into some details. Mac download sims 4 free. This is useful when exactly one object is needed to coordinate actions across the system. Software design patterns cheat sheet. Defines a family of algorithms encapsulates each one and make them interchangeable. Short cheatsheet of software design patterns. Design patterns quick reference.

System design interviews

Database scaling

System design interview preparation
  1. Horizontal scaling is ensured by adding concurrent machines that will handle more requests.
  2. Path1: The requests will be routed to SQL and it will become slow overtime. To make it better add more RAM, use sharding, denormalization, SQL tuning.
  3. Path 2: Better way to handle scale is denormalize right from beginning or switch to scalable no-sql DB. Even after that you'll need to introduce a cache.

Caching

  1. Users will see performance degradation when loads of data is fetched from the DBs. Cache needs to be implemented in such cases.
  2. In-memory cache like Redis or Memcached should be considered and not file based caching.
    1. Data is stored in the RAM.
    2. Redis can do 100s of 1000s of reads/second.
    3. Writes(including incremental ones) are faster too.
  3. Cache sits between storage and application.
  4. 2 patterns are:
    1. Cached database queries
    2. Cached objects
  1. Store the query and its result in the cache.
  2. Query is the key and result is value.
  3. Problem: If just a column or row changes, you need to remove all the key-value pairs that reside in the cache. That row or column might be used by a lot of queries and might be present in a lot of results. So its not an ideal approach.
  1. Store the class instance so that you can get rid of it if something changes.
  2. If one DB column value has changed then you need to get rid of the relevant object and not complete object.
  3. So its an ideal approach.
  1. Sessions
  2. User activity stream like twitter
  3. Fully rendered blog posts
  4. user <-> friend relationships

Types of asynchronism

A. For mostly static data that doesn't require a lot of pre-computation:

System Design Interviews

System design interview tipsCheat
Sheet
  1. Website pages that are built with frameworks or CMS should be pre-rendered and stored on AWS or CDN.
  2. Cron job performs these operations and store/push them on CDNs.
  3. This will make the site super responsive and could handle multiple requests.

System Design Interview Cheat Sheet

B. For dynamic data that requires intensive computation:

  1. User comes to the site and requests an operation to be performed.
  2. Site informs the user that its processing the task and informs the user once the job is done.
    1. When the task comes it is placed in the queue.
    2. Worker process will come and pick up the task from the queue. It will process it.
    3. The worker process finishes the job and informs the Front end about it.
    4. FE receives the signal and update the user.
    5. Technologies used for queuing are: Redis list, RabbitMQ, ActiveMQ

System Design Cheat Sheet Excel


Source:
http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones
http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database
http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache
http://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism