Please enable JavaScript.

Coggle requires JavaScript to display documents.

SystemDesign (Scale Pizza parlour (Should same manager manage delivery…

- - - - vertical scaling
      - prepare pizza base, beforehand at non peak hour
  - - - Resiliency
      - Master-slave
        
        Write into master first.
        Read from any slave.
        If master goes down, then slaves choose a master among themselves
      - Avoid single point of failure, and keep backups
  - - - Route all garlic bread requests to garllic bread team, and distribute pizza requests to pizza team
        
        Dividing responsibilities
        
        All your responsibilities are well defined
        
        Micro Services Architecture
        
        Not handling anything outside business use case
        
        Scaling both teams at different rate
  - - - Distributed systems
        Partitioning
      - Communication and routing can be a headache
      - you can always go to this shop if the order came from close by
  - - - Load balancer
  - - - Separation of concers/responsibilities
        
        De-coupling
    - - Extensible
- - - - Twitter: Keep new celeb tweets on top of cahce
  - - - Fast
      - But what if server fails?
      - What if data on different server cache gets inconsistent?
    - - If one server crashes then its ok, its more resilient
      - Not as fast
      - Can be scaled separately
      - RedIS
- - - - Another load balancer for resiliency
        
        put multiple IPs in DNS pointing to load balancer
- - - - HDFS: Good for Big Files, like Youtube videos.
      - Bigtable: Reading small amount of data, like Youtube thumbnails.
      - Cassandra: Wide column database, the names and format of the columns can vary from row to row in the same table
        Instagram: User & Photos, Users and Followers relationship.
      - ACID
        Atomicity: All or nothing.
        Consistency: Only valid data must be saved.
        Isolation: Independently processed, without interference, does not ensure the order of transaction.
        Durability: Written Data can not be lost.
- - - - Insertion and retrieval is one shot
      - One column can have another type of object, avoiding joins
      - Schema is flexible, if something is not available, then JSON ignores that entirely rather than saving as a null
    - - built for scale
    - - Consistency is an issue, ACID is not gauranteed
        
        Not transactional properties
    - - Give Age column for all employees
- - - - Single point of failure
      - Consistent
      - Inter process communication: Fast
    - - Requires load balancing
        More resilient
      - Data inconsistency
        
        if a transaction is happening between different servers, then you might need to lock all DBs which is impractical.
      - RPC over network
- - - - Adding new server behind load balancer, should not make big changes to the scheme
- - - - Isssues
        
        When a join is required
      - use consistent hashing
        
        you can pre-index, like on age>50 in newyork
- - - - to remove this you can introduce publisher/subscriber model between services by using message broker.
        Messages are fire and forget, so service1 can immediately send a response to client without waiting for a response from other clients.
        
        In terms of financial systems you don't want to run into a situation where transaction fees service is fired without amount transfer service executing successfully.
        This can lead to Poor Consistency(all the data across all the local DBs for all the services should be consistent) as we have entry for transaction fees service, but not for amount transfer.
        This does not guarantee Transaction Autonomy
        Doesn't guarantee Idempotency
        
        In Event Driven architecture services are publishing events rather than asking for information as in publisher subscriber model.
        And each service manages its event logs to replay the series of events and debug issues.