The latest articles on DEV Community by Harshit Sharma (@harshit_sharma_83a1c3b54e). https://dev.to/harshit_sharma_83a1c3b54e https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3521928%2F029877f7-62fe-4dd8-81cd-03d40434f228.png https://dev.to/harshit_sharma_83a1c3b54e en Harshit Sharma Mon, 22 Sep 2025 12:27:28 +0000 https://dev.to/harshit_sharma_83a1c3b54e/api-gateway-vs-varnish-for-api-security-traffic-control-n24 https://dev.to/harshit_sharma_83a1c3b54e/api-gateway-vs-varnish-for-api-security-traffic-control-n24 <p>We operate a backend API stack on GCP. Currently:</p> <ul> <li><p>Varnish handles caching + SourceIP authentication.<br> (IP refers to the infrastructure servers’ IPs, while Source is a URL parameter passed in API calls that identifies the property.)</p></li> <li><p>Both Varnish and backend run on the same GCP server.</p></li> </ul> <p>As we scale for resilience and performance, we need to implement:</p> <p><strong>Authentication &amp; Validation</strong></p> <ul> <li><p>Route requests to the correct backend.</p></li> <li><p>Enforce API key + SourceIP-based auth.</p></li> <li><p>Validate identities via parameters:</p></li> <li><p>Source (URL param, used in backend calls)</p></li> <li><p>IP (frontend server IPs)</p></li> <li><p>USR-ID (end-user ID, from URL param)</p></li> </ul> <p><strong>Rate Limiting</strong></p> <ul> <li><p>Based on Source + IP + USR-ID.</p></li> <li><p>Alert at x% of the threshold. Block at y% (API Gateway) or z% (Varnish).</p></li> <li><p>Configurable block durations.</p></li> </ul> <p><strong>Circuit Breaking / Backend Protection</strong></p> <ul> <li><p>Stop routing on backend failure.</p></li> <li><p>Note: In Varnish, we use a heartbeat health-check mechanism that is similar to a circuit breaker, but not a true implementation</p></li> </ul> <p><strong>Logging &amp; Observability</strong></p> <ul> <li><p>Track rate-limit breaches, blocks, circuit-breaking events, and request metadata.</p></li> <li><p>Alerts on abnormal traffic or backend failures.</p></li> </ul> <p>Options We’re Considering</p> <ol> <li><strong>API Gateway (New Development)</strong></li> </ol> <ul> <li>Central entry point for traffic.</li> <li>Handles auth, routing, rate limiting, logging, and observability.</li> <li>Centralised logic → easier management as APIs grow.</li> <li>Adds an extra hop, but increases visibility + maintainability.</li> </ul> <ol> <li><strong>Enhanced Varnish (Current, with Modifications)</strong></li> </ol> <ul> <li>Already deployed per server.</li> <li>Would need manual updates for: rate limiting (Source/IP/USR-ID), logging, and backend protection.</li> <li>No true circuit breaker, but can serve stale cache or block during backend downtime.</li> </ul> <p><strong>Key Questions</strong></p> <ul> <li><p>Centralisation vs Distribution: Better to centralise controls in an API Gateway, or enhance Varnish on each server??</p></li> <li><p>Performance &amp; Maintenance: Does the extra hop of an API Gateway outweigh its benefits in observability and control??</p></li> <li><p>Scaling with Varnish: How do you avoid config drift and manage scaling in a Varnish-based setup??</p></li> <li><p>Deployment Topology: Should Varnish and backend run on the same GCP server, or be separated for resilience??</p></li> <li><p>Real-World Experiences: Has anyone migrated from Varnish-based controls to an API Gateway?? What worked, what didn’t??</p></li> </ul> <p>Looking for:</p> <ul> <li>Real-world experiences</li> <li>Best practices</li> <li>Resource recommendations</li> </ul> apigateway varnish backend backenddevelopment