distributed-rate-limiter
Problem
APIs müssen vor Missbrauch und Überlastung geschützt werden, aber traditionelle Rate-Limiter mit In-Memory-State skalieren nicht über mehrere Instanzen, während synchrones Datenbank-Logging unter hohem Durchsatz inakzeptable Latenz erzeugt.
Lösung
Eine zweistufige Architektur: synchrone Redis-Lua-Token-Buckets für Rate-Entscheidungen unter 5ms (Fail-Open bei Redis-Ausfall), mit asynchronem Kafka-Event-Streaming für die Audit-Persistenz — durch getrennte Rate-Limiter- und Audit-Consumer-Services.
Java Spring Boot Redis Apache Kafka PostgreSQL Docker Testcontainers k6
<5ms
P99-Latenz 6 ADRs
Architekturentscheidungen Testcontainers
Teststrategie Fail-Open
Resilienz