Integrating additional security measures into existing authentication systems often introduces operational risks. With our new Caddy plugin, we shift this layer into the infrastructure. A load test with 40,000 requests demonstrates the stability of this architecture. For technical decision-makers, the authentication process is a mission-critical component. Any modification to the core codebase increases the risk of system failures. Introducing new verification mechanisms—such as checking for leaked passwords—typically requires refactoring and managing new dependencies in the backend. However, a fundamental requirement remains non-negotiable: The latency or failure of a third-party service must not disrupt the standard login process for end users. Approach: Quality Assurance at the Edge Instead of requiring teams to modify their backend implementations (Node, PHP, Go, Java), we are pursuing an infrastructure-based approach. With the official caddy-hansestack plugin for the Caddy reverse proxy, the security QA layer is completely decoupled from the application. In the intended enrich_response mode, the system operates as follows: The plugin acts as middleware. It intercepts the request, securely extracts the password using k-anonymity, and immediately passes the original login request to the backend in parallel. The backend implementation remains untouched and processes the login normally. Caddy simply waits for the asynchronous API result before sending the response and injects the HTTP header (X-Hansestack-Leaked: true) into the outgoing response to the client. This requires no code changes in the backend and adds no latency to the primary login process. System Behavior Under Load An architectural concept must prove itself under extreme conditions. To validate its reliability, we subjected the system to a controlled load test. In an isolated demo setup, we simulated 40,000 concurrent login attempts (in 40 blocks of 1,000 background processes) targeting the local Caddy server using a bash script: for j in $(seq 40); do \ for i in $(seq 1000); do \ curl --silent --url '[http://127.0.0.1/login](http://127.0.0.1/login)' \ --data-raw '{"email":"demo@example.com","password":"asdfghjkl;\\"}' & \ done; \ done; The objective was to intentionally overload the system to measure the behavior of the integrated circuit breaker. The Traffic Overview in the Grafana dashboard visualizes the load curve: (The load spike of 40,000 requests is fully processed by the Caddy proxy, while the backend processes continue undisturbed.) Detailed metrics from the Verdicts, Fail-Open Outcomes, and Health sections: (Metrics post-load test: Over 36,700 requests were intercepted by the fail-open mechanism. Zero client errors occurred.) Anatomy of Resilience (Fail-Open) The recorded metrics confirm the intended fault tolerance of the decoupled architecture: Initial Processing (Checked: 1,307): The Hansestack API processes the first 1,307 requests normally and correctly identifies the test password as compromised. Rate Limiting (Rate Limited: 1,924): Due to the massive concurrency, the API's protection mechanism engages. 1,924 requests are rate-limited. Six additional requests fail due to local network congestion (Skip Error: 6). Circuit Breaker Activation: The Caddy plugin registers these failures at the edge. After five consecutive errors, the circuit breaker activates according to its configuration. Graceful Degradation (Circuit Open: 36,715): The system transitions into Fail-Open mode. The remaining 36,715 requests hit the open circuit breaker. They are passed through locally without an API call (and formally evaluated as not leaked) to relieve the external interface and prevent blocking the auth flow. Result and Latencies: The system recorded 0 Client Errors. The delivery of requests to the backend was maintained throughout. The measured latencies document the stability: The p50 (median) was 2.73 ms, p95 at 150 ms, and the p99 percentile at 345 ms—significantly below the defined 500ms timeout. The login process remained fully performant while the security layer managed the overload condition. Conclusion Additional verification mechanisms in the auth flow must not compromise system stability. Shifting the k-anonymity leak check into the reverse proxy as an enrich_response middleware, secured by circuit breakers, provides reliable security metrics with minimal implementation effort while safeguarding the core business. Resources & Hands-on: 🐙 The Plugin: Check out the caddy-hansestack module on GitHub. (If you like this architectural approach, a GitHub ⭐️ is highly appreciated!) 👾 Reproducibility: The complete 40k load test setup (Caddy, backend, Prometheus, Grafana) is available as an open-source sandbox. Run the interactive demo here. 📖 Documentation: Read the full integration guide in the Hansestack Docs.