4. Reverse proxy (web server)
    
A reverse proxy is a web server that centralizes internal services and provides unified interfaces to the public.  Requests from clients are forwarded to a server that can fulfill it before the reverse proxy returns the server's response to the client.
Additional benefits include:

• Increased security - Hide information about backend servers, blacklist IPs, limit number of connections per client
• Increased scalability and flexibility - Clients only see the reverse proxy's IP, allowing you to scale servers or change their configuration
• SSL termination - Decrypt incoming requests and encrypt server responses so backend servers do not have to perform these potentially expensive operations
  
  • Removes the need to install X.509 certificates on each server
    
• Compression - Compress server responses
• Caching - Return the response for cached requests
• Static content - Serve static content directly
  
  • HTML/CSS/JS
  • Photos
  • Videos
  • Etc
    

Load balancer vs reverse proxy

• Deploying a load balancer is useful when you have multiple servers.  Often, load balancers  route traffic to a set of servers serving the same function.
• Reverse proxies can be useful even with just one web server or application server, opening up the benefits described in the previous section.
• Solutions such as NGINX and HAProxy can support both layer 7 reverse proxying and load balancing.
  

Disadvantage(s): reverse proxy

• Introducing a reverse proxy results in increased complexity.
• A single reverse proxy is a single point of failure, configuring multiple reverse proxies (ie a failover) further increases complexity.
  

Source(s) and further reading

• Reverse proxy vs load balancer
• NGINX architecture
• HAProxy architecture guide
• Wikipedia
  

5. Application layer
    
Separating out the web layer from the application layer (also known as platform layer) allows you to scale and configure both layers independently.  Adding a new API results in adding application servers without necessarily adding additional web servers.  The single responsibility principle advocates for small and autonomous services that work together.  Small teams with small services can plan more aggressively for rapid growth.
Workers in the application layer also help enable asynchronism.
MicroservicesRelated to this discussion are microservices, which can be described as a suite of independently deployable, small, modular services.  Each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.
Pinterest, for example, could have the following microservices: user profile, follower, feed, search, photo upload, etc.
Service DiscoverySystems such as Consul, Etcd, and Zookeeper can help services find each other by keeping track of registered names, addresses, and ports.  Health checks help verify service integrity and are often done using an HTTP endpoint.  Both Consul and Etcd have a built in key-value store that can be useful for storing config values and other shared data.
Disadvantage(s): application layer

• Adding an application layer with loosely coupled services requires a different approach from an architectural, operations, and process viewpoint (vs a monolithic system).
• Microservices can add complexity in terms of deployments and operations.
  

Source(s) and further reading

• Intro to architecting systems for scale
• Crack the system design interview
• Service oriented architecture
• Introduction to Zookeeper
• Here's what you need to know about building microservices