Introduction

Nginx is the backbone of the modern internet. As of 2021, it serves more than 35% of all websites worldwide, making it the most widely used web server on the planet. Its event-driven architecture handles thousands of concurrent connections with minimal memory usage, which is why companies like Netflix, Airbnb, and Cloudflare rely on it for their infrastructure.

A reverse proxy sits between clients and your backend servers, forwarding requests and returning responses. This simple concept unlocks powerful capabilities: SSL termination, load balancing, caching, compression, rate limiting, and security hardening. By placing Nginx in front of your application servers, you create a single entry point that handles all the concerns that do not belong in your application code.

This guide covers everything you need to configure Nginx as a production-grade reverse proxy, from basic setup to advanced optimization techniques that can dramatically improve your application performance and reliability.

Understanding Nginx Architecture: Core Concepts

Event-Driven Processing Model

Unlike Apache process-per-connection model, Nginx uses an event-driven, non-blocking architecture. A single Nginx worker process can handle thousands of simultaneous connections through epoll (Linux) or kqueue (BSD/macOS) system calls. This design makes Nginx extremely efficient for high-concurrency workloads.

The master process reads configuration, binds to ports, and spawns worker processes. Worker processes handle all the actual request processing. Each worker runs an event loop that processes connections without blocking, allowing a small number of workers to handle massive traffic loads.

# /etc/nginx/nginx.conf - Core configuration
user nginx;
worker_processes auto;  # Usually equals number of CPU cores
worker_rlimit_nofile 65535;
 
events {
    worker_connections 4096;
    multi_accept on;
    use epoll;
}
 
http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    
    # Logging
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log warn;
    
    # Gzip compression
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml;
    
    include /etc/nginx/conf.d/*.conf;
}

How a Reverse Proxy Works

When a client sends a request to your server, Nginx receives it, processes it according to your configuration, and forwards it to the appropriate backend server. The backend processes the request and returns a response to Nginx, which then sends it back to the client.

This indirection provides several benefits. The client never communicates directly with your backend, hiding your internal architecture. Nginx can modify requests and responses, add headers, compress content, and cache responses. SSL termination happens at the Nginx layer, so your backend servers do not need to handle encryption.

The Configuration File Structure

Nginx configuration uses a hierarchical block structure. The main context contains events and http blocks. The http block contains server blocks, which define virtual hosts. Each server block contains location blocks that match specific URLs.

# Server block - defines a virtual host
server {
    listen 80;
    server_name example.com www.example.com;
    
    # Location block - matches specific URLs
    location / {
        proxy_pass http://backend;
    }
    
    location /api/ {
        proxy_pass http://api_backend;
    }
    
    location /static/ {
        alias /var/www/static/;
        expires 30d;
    }
}

Architecture and Design Patterns

Upstream Configuration

The upstream block defines a group of backend servers that Nginx can proxy requests to. This is the foundation of load balancing and failover.

# Define backend servers
upstream app_backend {
    # Load balancing method (default: round-robin)
    least_conn;
    
    # Backend servers with optional weights
    server 10.0.0.1:3000 weight=3;
    server 10.0.0.2:3000 weight=2;
    server 10.0.0.3:3000 weight=1;
    
    # Backup server (only used when all primary servers are down)
    server 10.0.0.4:3000 backup;
    
    # Keep connections alive to backend servers
    keepalive 32;
}
 
server {
    listen 80;
    server_name example.com;
    
    location / {
        proxy_pass http://app_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

Load Balancing Algorithms

Nginx supports several load balancing algorithms, each suited to different workloads.

Round Robin distributes requests evenly across servers in order. This is the default and works well when all servers have similar capacity and request processing times.

Least Connections sends requests to the server with the fewest active connections. This is better when request processing times vary, as it prevents slow requests from piling up on a single server.

IP Hash routes requests from the same client IP to the same server. This provides session affinity without cookies, which is useful for stateful applications that cannot share session data across servers.

# Round Robin (default)
upstream backend_rr {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
}
 
# Least Connections
upstream backend_lc {
    least_conn;
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
}
 
# IP Hash
upstream backend_hash {
    ip_hash;
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
}

SSL Termination

SSL termination at the Nginx layer means Nginx handles all HTTPS encryption and decryption, forwarding plain HTTP requests to your backend servers. This simplifies your backend configuration and centralizes certificate management.

server {
    listen 443 ssl http2;
    server_name example.com;
    
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    
    # Modern SSL configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    
    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    
    # SSL session caching
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;
    
    # Security headers
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options SAMEORIGIN always;
    
    location / {
        proxy_pass http://app_backend;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;
    }
}
 
# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Step-by-Step Implementation

Basic Reverse Proxy Setup

The simplest reverse proxy configuration forwards all requests to a single backend server.

server {
    listen 80;
    server_name example.com;
    
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The proxy_set_header directives are critical. Without them, your backend server will not know the original client IP address, the original protocol, or the original host header. Most application frameworks use these headers for logging, security, and URL generation.

Advanced Proxy Configuration

Production setups need timeout configuration, buffer management, and error handling.

upstream node_app {
    least_conn;
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
    server 127.0.0.1:3003;
    keepalive 64;
}
 
server {
    listen 80;
    server_name example.com;
    
    # Proxy timeouts
    proxy_connect_timeout 10s;
    proxy_send_timeout 30s;
    proxy_read_timeout 30s;
    
    # Proxy buffers
    proxy_buffer_size 16k;
    proxy_buffers 8 16k;
    proxy_busy_buffers_size 32k;
    
    # Proxy headers
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Request-ID $request_id;
    
    # WebSocket support
    location /ws/ {
        proxy_pass http://node_app;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 86400s;
    }
    
    # API routes
    location /api/ {
        proxy_pass http://node_app;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
    
    # Static files with caching
    location /static/ {
        alias /var/www/app/static/;
        expires 30d;
        add_header Cache-Control "public, immutable";
        access_log off;
    }
    
    # Default route
    location / {
        proxy_pass http://node_app;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

Real-World Use Cases

Use Case 1: Microservices Gateway

Nginx serves as an API gateway that routes requests to different microservices based on the URL path. Each service runs on its own port or server, and Nginx unifies them under a single domain.

server {
    listen 443 ssl http2;
    server_name api.example.com;
    
    ssl_certificate /etc/ssl/api.example.com.crt;
    ssl_certificate_key /etc/ssl/api.example.com.key;
    
    # User service
    location /users/ {
        proxy_pass http://user-service:4000/;
        limit_req zone=api burst=20 nodelay;
    }
    
    # Product service
    location /products/ {
        proxy_pass http://product-service:4001/;
        limit_req zone=api burst=20 nodelay;
    }
    
    # Order service
    location /orders/ {
        proxy_pass http://order-service:4002/;
        limit_req zone=api burst=10 nodelay;
    }
    
    # Search service with caching
    location /search/ {
        proxy_pass http://search-service:4003/;
        proxy_cache search_cache;
        proxy_cache_valid 200 5m;
        proxy_cache_use_stale error timeout updating;
    }
}

Use Case 2: Blue-Green Deployment

Nginx makes blue-green deployments trivial by switching the upstream definition. You deploy the new version to a separate server group, test it, then switch traffic by updating the upstream.

# Active: blue
upstream app {
    server 10.0.0.1:3000;  # Blue
    # server 10.0.0.2:3000;  # Green (inactive)
}
 
# Switch to green by changing comments and reloading
# nginx -s reload with zero downtime

Use Case 3: Static Asset CDN with Dynamic Backend

Nginx can serve static assets directly while proxying dynamic requests to your application server. This offloads static file serving from your application and allows you to set aggressive caching headers.

Best Practices for Production

1. Use proxy_http_version 1.1: HTTP 1.1 supports keep-alive connections to backend servers, reducing connection overhead significantly.

2. Set proxy_set_header Connection "": When using keep-alive with upstream, clear the Connection header to prevent it from being forwarded.

3. Enable proxy_buffering: Buffering allows Nginx to read the entire backend response before sending it to the client, which frees up backend connections faster.

4. Configure appropriate timeouts: Set proxy_connect_timeout short (5-10s) to detect backend failures quickly. Set proxy_read_timeout based on your longest expected request.

5. Use least_conn for varied workloads: If your requests have different processing times, least connections load balancing distributes load more evenly than round robin.

6. Enable gzip compression: Compress text-based responses to reduce bandwidth. Exclude already-compressed formats like images and videos.

7. Implement rate limiting: Protect your backend from traffic spikes and abuse using limit_req and limit_conn directives.

8. Log the right information: Include upstream response time, request ID, and client IP in your logs for debugging and monitoring.

log_format main '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent" '
                'rt=$request_time uct=$upstream_connect_time '
                'uht=$upstream_header_time urt=$upstream_response_time';

Common Pitfalls and Solutions

Performance Optimization

Response Caching

Nginx caching can dramatically reduce backend load for repeated requests. Define a cache zone in the http block and apply it to specific locations.

# In http block
proxy_cache_path /var/cache/nginx levels=1:2 
    keys_zone=app_cache:10m 
    max_size=1g 
    inactive=60m 
    use_temp_path=off;
 
server {
    listen 80;
    server_name example.com;
    
    location /api/products {
        proxy_pass http://backend;
        proxy_cache app_cache;
        proxy_cache_valid 200 10m;
        proxy_cache_valid 404 1m;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503;
        proxy_cache_lock on;
        proxy_cache_lock_timeout 5s;
        
        add_header X-Cache-Status $upstream_cache_status;
    }
}

Connection Optimization

# Upstream keepalive connections
upstream backend {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    keepalive 64;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}
 
server {
    # Client keepalive
    keepalive_timeout 65;
    keepalive_requests 100;
    
    # TCP optimization
    tcp_nopush on;
    tcp_nodelay on;
    
    # Open file cache
    open_file_cache max=10000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;
}

Comparison with Alternatives

Advanced Patterns and Techniques

Conditional Proxying Based on Headers

You can route requests to different backends based on request headers, cookies, or other variables. This is useful for A/B testing, canary deployments, and multi-tenant applications.

map $http_x_canary $backend_pool {
    "true"  canary_backend;
    default production_backend;
}
 
upstream production_backend {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
}
 
upstream canary_backend {
    server 10.0.0.3:3000;
}
 
server {
    listen 80;
    server_name example.com;
    
    location / {
        proxy_pass http://$backend_pool;
    }
}

Request Rate Limiting

http {
    # Define rate limit zones
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    
    server {
        location /api/ {
            limit_req zone=api_limit burst=20 nodelay;
            limit_conn conn_limit 10;
            proxy_pass http://backend;
        }
        
        location /auth/login {
            limit_req zone=login_limit burst=5 nodelay;
            proxy_pass http://backend;
        }
    }
}

Testing Strategies

Test your Nginx configuration before deploying changes. Use nginx -t to validate syntax, and nginx -T to dump the full configuration for review.

# Validate configuration
sudo nginx -t
 
# Test with curl
curl -I -H "Host: example.com" http://localhost/
curl -v https://example.com/api/health
 
# Check upstream health
curl http://localhost/nginx_status
 
# Load testing with hey
hey -n 10000 -c 100 https://example.com/

Future Outlook

Nginx continues to evolve with HTTP/3 and QUIC support, improved stream module for TCP and UDP proxying, and better integration with container orchestration platforms. The Nginx Unit project provides a dynamic application server that complements Nginx as a reverse proxy.

The rise of service meshes like Istio and Linkerd is shifting some proxy responsibilities from Nginx to sidecar proxies. However, Nginx remains the go-to choice for edge proxying, SSL termination, and static file serving.

Nginx Performance Monitoring

Monitor Nginx performance using the stub_status module, which exposes active connections, request rates, and connection state metrics. Enable access logging with timing information ($request_time, $upstream_response_time) to identify slow requests. Use tools like GoAccess or ELK stack to analyze access logs in real-time. Configure Nginx's built-in caching and monitor cache hit rates using the upstream_cache_status variable. Set up alerts for high error rates, excessive 502/504 responses, and upstream timeouts.

Performance Monitoring in Production

Setting up comprehensive performance monitoring ensures that your optimizations continue to deliver value after deployment. Without monitoring, performance regressions can silently accumulate as your application evolves, eventually degrading user experience below acceptable thresholds.

Real User Monitoring (RUM)

Real User Monitoring captures performance metrics from actual users in production environments, providing data that synthetic benchmarks cannot replicate. Implement RUM by collecting Core Web Vitals metrics from the web-vitals library and sending them to your analytics platform:

import { onCLS, onFID, onLCP, onINP, onTTFB } from 'web-vitals';
 
function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
    page: window.location.pathname,
    connection: navigator.connection?.effectiveType,
    deviceMemory: navigator.deviceMemory,
  });
 
  // Use Beacon API for reliable delivery even during page unload
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/vitals', body);
  } else {
    fetch('/api/vitals', { body, method: 'POST', keepalive: true });
  }
}
 
onCLS(sendToAnalytics);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onTTFB(sendToAnalytics);

Performance Budgets

Establish performance budgets that prevent regressions from reaching production. Configure your CI pipeline to fail builds that exceed these budgets:

{
  "budgets": [
    {
      "type": "initial",
      "maximumWarning": "200kb",
      "maximumError": "250kb"
    },
    {
      "type": "bundle",
      "name": "vendor",
      "maximumWarning": "150kb",
      "maximumError": "200kb"
    }
  ]
}

Track bundle size changes in pull requests using tools like bundlewatch or size-limit. These tools compare the bundle size of the current branch against the base branch and report differences directly in the PR, making it easy to identify which changes introduced significant size increases.

Continuous Performance Regression Testing

Integrate Lighthouse CI into your deployment pipeline to catch performance regressions before they reach production. Configure it to run against key pages and fail the build if any metric drops below your defined thresholds:

# lighthouserc.js
module.exports = {
  ci: {
    collect: {
      url: ['http://localhost:3000/', 'http://localhost:3000/dashboard'],
      numberOfRuns: 3,
    },
    assert: {
      assertions: {
        'categories:performance': ['error', { minScore: 0.9 }],
        'categories:accessibility': ['error', { minScore: 0.95 }],
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }],
      },
    },
  },
};

This automated approach ensures that every deployment maintains your performance standards, preventing the gradual degradation that occurs when performance is only manually tested.

Production Deployment and Operations

Running backend services in production requires attention to reliability, observability, and operational concerns that don't exist in development environments. Proper deployment practices ensure your service remains available and performant under real-world conditions.

Graceful Shutdown Handling

Implement graceful shutdown to prevent request failures during deployments and restarts:

const server = app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});
 
async function gracefulShutdown(signal) {
  console.log(`Received ${signal}, starting graceful shutdown...`);
 
  // Stop accepting new connections
  server.close(async () => {
    console.log('HTTP server closed');
 
    try {
      // Wait for existing requests to complete (with timeout)
      await Promise.race([
        waitForActiveRequests(),
        new Promise((_, reject) =>
          setTimeout(() => reject(new Error('Shutdown timeout')), 30000)
        ),
      ]);
 
      // Close database connections
      await db.destroy();
      await redis.quit();
 
      console.log('Graceful shutdown completed');
      process.exit(0);
    } catch (error) {
      console.error('Error during shutdown:', error);
      process.exit(1);
    }
  });
 
  // Force shutdown after timeout
  setTimeout(() => {
    console.error('Forced shutdown after timeout');
    process.exit(1);
  }, 35000);
}
 
process.on('SIGTERM', () => gracefulShutdown('SIGTERM'));
process.on('SIGINT', () => gracefulShutdown('SIGINT'));

Structured Logging

Replace console.log with structured logging that supports log aggregation and querying:

const pino = require('pino');
 
const logger = pino({
  level: process.env.LOG_LEVEL || 'info',
  formatters: {
    level(label) {
      return { level: label };
    },
  },
  serializers: {
    err: pino.stdSerializers.err,
    req: pino.stdSerializers.req,
    res: pino.stdSerializers.res,
  },
  redact: {
    paths: ['req.headers.authorization', 'req.headers.cookie'],
    remove: true,
  },
});
 
// Request logging middleware
app.use((req, res, next) => {
  const start = Date.now();
  res.on('finish', () => {
    logger.info({
      req,
      res,
      responseTime: Date.now() - start,
    }, `${req.method} ${req.url} ${res.statusCode}`);
  });
  next();
});

Rate Limiting and Abuse Prevention

Protect your API endpoints with rate limiting that adapts to different client types:

const rateLimit = require('express-rate-limit');
const RedisStore = require('rate-limit-redis');
 
const apiLimiter = rateLimit({
  store: new RedisStore({ client: redisClient }),
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100, // 100 requests per window
  standardHeaders: true,
  legacyHeaders: false,
  keyGenerator: (req) => req.user?.id || req.ip,
  handler: (req, res) => {
    logger.warn({ ip: req.ip, user: req.user?.id }, 'Rate limit exceeded');
    res.status(429).json({
      error: 'Too many requests',
      retryAfter: Math.ceil(req.rateLimit.resetTime / 1000),
    });
  },
});
 
app.use('/api/', apiLimiter);

These operational practices form the foundation of a reliable production service that can handle real-world traffic patterns and failure scenarios.

Community Resources and Further Learning

The technology landscape evolves rapidly, making continuous learning essential for maintaining expertise. Building a systematic approach to staying current with developments in your technology stack ensures you can leverage new features and avoid deprecated patterns.

Curated Learning Pathways

Rather than consuming content randomly, create structured learning pathways aligned with your current projects and career goals. Start with official documentation and specification documents, which provide the most accurate and comprehensive information. Follow this with hands-on tutorials and workshops that reinforce concepts through practical application.

Technical blogs from framework maintainers and core team members often provide deeper insights into design decisions and upcoming features. Subscribe to the official blogs of your primary frameworks and libraries to stay ahead of breaking changes and deprecation timelines.

Contributing to Open Source

Contributing to open-source projects in your technology stack provides unparalleled learning opportunities. Start with documentation improvements and bug reports, then progress to fixing small issues tagged as "good first issue" in your favorite projects. This direct engagement with maintainers and the codebase accelerates your understanding far beyond what passive learning can achieve.

# Setting up for contribution
git clone https://github.com/project/repository.git
cd repository
git checkout -b fix/issue-description
 
# Run the project's contribution setup
npm run setup:dev
npm run test  # Ensure tests pass before making changes
 
# Make your changes, then run the full test suite
npm run test:full
npm run lint
npm run build
 
# Submit your contribution
git add -A
git commit -m "fix: description of the fix
 
Closes #1234"
git push origin fix/issue-description

Building a Technical Knowledge Base

Maintain a personal knowledge base that captures insights, solutions, and patterns you discover during your work. Tools like Obsidian, Notion, or even a simple Markdown repository can serve as an external memory that grows more valuable over time.

Organize your notes by topic rather than chronologically, and include code examples, links to relevant documentation, and explanations of why certain approaches work better than others. When you encounter a particularly insightful article or conference talk, write a summary that captures the key takeaways and how they apply to your current projects.

Staying Current with Industry Trends

Follow key conferences and their published talks to stay informed about emerging patterns and best practices. Many conferences publish recorded talks on YouTube within weeks of the event, making world-class technical content freely accessible.

Join relevant Discord servers, Slack communities, and forums where practitioners discuss real-world challenges and solutions. These communities provide early warning about emerging issues and access to collective wisdom that isn't available through formal documentation.

Mentorship and Knowledge Sharing

Teaching others is one of the most effective ways to deepen your own understanding. Consider writing technical blog posts, giving talks at local meetups, or mentoring junior developers. The process of explaining concepts to others forces you to organize your knowledge and identify gaps in your understanding.

Pair programming sessions with colleagues of different experience levels create mutual learning opportunities. Senior developers gain fresh perspectives on problems they've solved the same way for years, while junior developers benefit from exposure to production-grade thinking and decision-making processes.

Conclusion

Nginx reverse proxy configuration is a fundamental skill for any backend or DevOps engineer. Its event-driven architecture, flexible configuration, and rich feature set make it the standard for production web infrastructure.

Key takeaways:

1. Always set proper proxy headers to preserve client information
2. Use upstream keepalive connections to reduce backend connection overhead
3. Enable SSL termination at the Nginx layer to simplify backend configuration
4. Implement rate limiting to protect your backend from abuse
5. Use proxy caching for repetitive read-heavy workloads
6. Monitor upstream response times and error rates for proactive issue detection
7. Test configuration changes before deploying to production
8. Use least_conn load balancing for varied request processing times

Start with a basic reverse proxy configuration and incrementally add SSL, caching, rate limiting, and load balancing as your application grows. Nginx modular approach makes it easy to add capabilities without rewriting your configuration from scratch.