Please enable JavaScript.

Coggle requires JavaScript to display documents.

Scaling (Principles to make Scalable (Store config file in the environment…

- - - - Local Host - no need to scale
    - - Nginx can handle this traffic well as it uses an event model
      - NodeJS is event-driven and non-blocking and handles calls asynchronously and can take multiple requests
      - App can be a single app right now
    - - Requests may take longer here and things become slower - especially if NodeJS has to do a long calculation
        
        Need more hardware - Vertical Scaling
        
        Get more resources such as faster CPU, RAM and HDD
        
        More Cores now to fork and cluster NodeJS process and now load balance with Nginx to achieve little downtime
      - Nginx will cache static files and any request that needs the app will get forwarded by Nginx (reverse proxy)
    - - Database taking longer to respond - Instead of having database on one server which has e.g 4 CPUs - instead can have 4 Servers with one CPU running 4 copies of database answering different calls
      - Horizontal Scaling
      - Cheaper than to continue Vertical Scaling and better than having all eggs in one basket so if server is down App crashes
      - Also start to add caching
      - Look at the files /etc/security/limits.d and /etc/sysctl.conf as these files limit maximum number of requests via the net.core.somaxconn which default to 128 and you can to 1024 to meet users
    - - Add a load balancer (ELB with Route 53 in AWS)
        ELB will give performance analysis and can manage 1000 instances
      - Use multiple availability zones in region (AWS)
      - Split static files to different servers for easier maintenance e.g. a AWS S3 and Cloudfront CDN
      - Add a CDN for optimizing cross-origin performance and lower the latency
      - Grow horizontally rather than vertically
        
        Separate Web app from database and scale each one with more instances
    - - Keep using Vertical and Horizontal Solutions but now need to split the Codebase
      - Break code into smaller pieces and scale accordingly
      - Start Micro-services and scale them
        
        Use a load balancer to redirect the traffic to the new small service instead of the main app
    - - High availability and multi-region
        
        Keep adding instances in specific regions
      - Autoscaling
        
        Adjust to traffic conditions
      - Automate as much as you can
      - Metrics
        
        Monitor everything and log everything
        
        Use Elasticsearch for a centralized logging solution to log into server if it goes down
        
        Monitoring via Datadog - the best
      - Customisation