Menu
Dev.to #systemdesign·June 10, 2026

Understanding the Request Journey: Key Infrastructure Components Before Code Execution

This article provides a foundational overview of the critical infrastructure layers that process a user's request before it reaches an application's backend code. It explains the roles of CDNs, WAFs, Load Balancers, API Gateways, Internal Reverse Proxies, Rate Limiters, and Input Sanitization. The content uses analogies to simplify complex concepts, making it accessible for those new to system design, and emphasizes the importance of each component in building robust, scalable, and secure applications.

Read original on Dev.to #systemdesign

Before an application's business logic even begins to execute, a user's request navigates through a sophisticated gauntlet of infrastructure components. Understanding this journey is fundamental to designing scalable, performant, and secure distributed systems. This overview highlights the key layers involved in handling a web request from the client to the backend.

The Request Path: Essential Infrastructure Layers

  1. Content Delivery Network (CDN): Acts as a distributed cache, serving static and dynamic content from edge locations geographically closer to users. This significantly reduces latency and offloads traffic from origin servers, improving user experience and application performance.
  2. Web Application Firewall (WAF): A security layer that filters, monitors, and blocks malicious HTTP traffic before it reaches the application. WAFs protect against common web vulnerabilities like SQL injection, cross-site scripting (XSS), and DoS attacks by enforcing security rules.
  3. Load Balancer: Distributes incoming network traffic across multiple backend servers. This ensures high availability, maximizes throughput, and prevents any single server from becoming a bottleneck, even if one fails.
  4. API Gateway: Serves as the single entry point for all API requests, handling cross-cutting concerns such as authentication, authorization, rate limiting, logging, and routing requests to appropriate microservices. It acts as a 'watchman' for the entire system.
  5. Internal Reverse Proxy: Often used within a microservices architecture to route requests from the API Gateway to specific internal services based on request paths or other criteria. It acts as a 'guide' for internal traffic.
  6. Rate Limiting: A mechanism to control the rate at which an API or service can be accessed by a user or client within a defined time window. This prevents abuse, protects against DoS attacks, and ensures fair usage of resources. A common implementation involves using a fast in-memory store like Redis to maintain counters.
  7. Input Sanitization: The critical process of cleaning and validating user-supplied data to prevent malicious inputs from being processed by the application. This is a fundamental security practice to mitigate risks like injection attacks (SQL, XSS, command injection).
💡

Architectural Consideration: Layered Security and Performance

Each layer in the request journey contributes to the overall security, performance, and reliability of an application. System designers must carefully consider the placement and configuration of these components to optimize for specific requirements. For instance, caching at the CDN level reduces load on subsequent layers, while a WAF provides an early line of defense against attacks, complementing internal input sanitization.

The Role of Proxies: API Gateway vs. Internal Reverse Proxy

While both API Gateways and Internal Reverse Proxies perform routing, their roles are distinct. An API Gateway acts as the external facing entry point, handling client-facing concerns like API versioning, authentication, and request aggregation for microservices. An Internal Reverse Proxy typically operates behind the API Gateway, managing internal routing between different microservices or groups of services, often in a more granular fashion without the broader API management responsibilities.

python
# Conceptual example of a rate limiter using Redis
import redis
import time

def is_rate_limited(user_id, limit, window_seconds):
    r = redis.Redis(host='localhost', port=6379, db=0)
    key = f'rate_limit:{user_id}'
    current_time = int(time.time())
    
    # Remove timestamps older than the window
    r.zremrangebyscore(key, 0, current_time - window_seconds)
    
    # Add current request timestamp
    r.zadd(key, {current_time: current_time})
    
    # Set expiration for the key
    r.expire(key, window_seconds + 5) # +5 for buffer
    
    # Check current count
    count = r.zcard(key)
    return count > limit

# Example Usage
# user_id = 'test_user_1'
# if is_rate_limited(user_id, 5, 60): # 5 requests per minute
#     print('Rate limited!')
# else:
#     print('Request allowed.')
CDNWAFLoad BalancerAPI GatewayReverse ProxyRate LimitingSecurityInfrastructure

Comments

Loading comments...