Please enable JavaScript.

Coggle requires JavaScript to display documents.

scalable-system-design - Coggle Diagram

- - - - amount of data
      - stable, consistent response time with growing request load
      - number of request
    - - increasing resources
      - this is simple
    - - run multiple copies of the application
      - needed elements
        
        stateless services
        
        user request are stateless
        
        state is stored outside of the application
        
        a load balancer
        
        receives request from client
        
        forward to the service
        
        receives response from server and send to client
        
        these are reverse proxies
        
        extremely low latency
      - at one point DB becomes bottleneck
        
        scaling DB with caching
        
        can use distributed cache
        
        memcache
        
        redis
        
        requires application logic change
        
        distributed database
        
        2 major categories
        
        distributed sql stores
        
        stores data in multiple disk
        
        disk queried by multiple db engine replica
        
        1 more item...
        
        uses sql to query data
        
        distributed NoSql stores
        
        data is distributed in variety of data model
        
        there are variety of query language
        
        data is distributed across multiple node
        
        each node has its own engine and locally attached storage
        
        promotes availability
        
        raises consistency issues
        
        db can be scaled up
        
        more cpu
        
        more memory
        
        more disk
      - multi-tired processing
        
        making multiple services load balanced and replicated
      - defer writing to DB
        
        use distributed queue to store the data
        
        writing to queue is faster than writing to DB
        
        this is eventual consistency
      - system and hardware scalability
        
        if code is not multithreaded, it can't be scaled even with powerful hardware
      - aka horizontal scalling
      - makes the application resilient to failure and highly available
        
        if one server fails others can continue to serve request
  - - - by replication
        
        increasing the resources
      - optimization
  - - - some optimization strategy may reduce the system capacity
    - - achieved by replication
        
        becomes complicated when there is state like db
        
        the problem of consistency raises head
- - - - chatty API
        
        avoid it
        
        multiple API call to do one logical operation
      - use compression for large payload
    - - HTTP
        
        supposed to be stateless
        
        HTTP/1 uses cookies for HTTP state management
        
        HTTP/2 supports streams, compression and encryption all of which require state management
      - to be scalable, services should not store any conversational state
    - - load balancer
        
        network level
        
        application level
  - - - patterns
        
        cache aside
        
        application implements cache miss logic
        
        tool Redis, Memcached
        
        highly scalable
        
        read through
        
        application reads from cache
        
        tool NCache
        
        write through
        
        application writes to cache, cache writes to DB
        
        write behind
        
        application writes to cache, cache writes to DB later
    - - only GET request is cached
        
        the URI is the cache key
  - - - push
        
        more efficient
      - pull
  - - - AWS lambda
      - Google App Engine
  - - - DDD is an approach
    - - deploy individual services independently
      - hide deployment details using API gateway pattern
        
        gateway tool
        
        NGNIX
        
        Kong