Please enable JavaScript.

Coggle requires JavaScript to display documents.

System design, CDN- Content Delivery Networks, Monolit architecture,…

- - - - High level desing diagram
        
        Load balancer -> servises ->DB
      - Data model and schema
        
        data access paterns
        
        read/write ratio
      - APIs - contract between user and backend
        
        follow RESTful convention
        
        check requests and responses
      - Review all high level design
  - - - come up with at least 2 solutions
      - discuss the trade-offs of the solutions
      - articulate the problem
      - pick the solution and discuss it with interwier
      - repeat for all problem
  - - - consistensy
      - scalability
        
        Scalability
        
        user-><-server - latensy, CPU
        
        Verticcal scaling
        
        increas processing power of single server
        
        pros
        
        data consistency
        
        fast inter-proccess cominications
        
        corn
        
        single point of failure
        
        economic(hardware) limits of scaling
        
        Horizontal scaling
        
        host the app in more servers that run in parallel
        
        pros
        
        more reliable
        
        scales lineary
        
        corns
        
        data inconsistancy
        
        difficult to manage
        
        RPC communications (network communication) - slower
        
        need load balancer
      - security
      - performance
      - freshness
      - availability
        
        HI availability = 99,999% = 5 min of downtime per year
        
        Availability paterns
        
        failover
        
        db & servers
        
        how we shift from failing component to others
        
        active-passive patern
        
        there are 2 servers active(recives requests) and passive(sleep and liasten heartbeets of active), one active is fall, passive start works - it's increase latency
        
        active - active patern
        
        there is load balancer and both servers are managing traffic, no downtimes - if one fall another is working
        
        replication
        
        relatives DB
        
        paterns
        
        primary & replica
        
        split read and write requests - write to one primary DB and read from replicas
        
        2 more items...
        
        primary & primary
        
        for each server his own primary DB for read/write(which are replicas for each other), servises are scale horizontaly
        
        2 more items...
- - - - depends on
        
        disaster type
        
        geografical impact
      - BCP
        
        business continuity plan - set of actions when disaster
    - - impact by
        
        network issues
        
        load spikes
        
        CDN допомаг зниз
        
        components failure
- - - - file
        
        Gave us
        
        faster - save images separetly, quick access
        
        CDN
        
        cheeper
      - blob - binary large object
      - DB gives us
        
        transaction - ACID
        
        useless for images
        
        indexes for search
        
        useless for images - image saves in format of 0 and 1
        
        mutability
        
        unnesessary for images
        
        access control
        
        useless - you can get same secure mechanism for files as for DB
        
        save parh to image in table but image stores in DFS - distributed file system
      - user -> reqest (update name) need to have autentification process(name, token) -> Gate way service-> profile servise -> DB->...-> response -> user
      - user-> request - update images -> gateway serv-> image servise-> DB (store user id, image id, name, path to DFS) and DFS
  - - - every user has his conection id
      - user-> gateway service-> session servise->DB - store user id and connection id