Rate Limiting et Throttling en C# : Maîtriser les flux de requêtes

Rate Limiting et Throttling en C# : Comment protéger votre API des surcharges et préserver la patience des utilisateurs

Imaginez : vous avez lancé une API géniale. Le serveur vole, la base de données répond instantanément. Mais soudain — boum ! — un client négligent (ou, pire encore, une attaque DDoS) commence à marteler votre point d'entrée avec des milliers de requêtes par seconde. Le serveur tombe, la base de données s'étouffe, et les vrais utilisateurs voient une erreur 503. Cela vous dit quelque chose ?

La solution à ce problème est le rate limiting (limitation de débit) et le throttling (étranglement). En C#, nous avons tous les outils pour implémenter ces mécanismes de manière élégante et efficace. Dans cet article, nous ne nous contenterons pas de survoler la théorie — nous écrirons du code réel, analyserons les algorithmes populaires et déterminerons quoi choisir pour une tâche spécifique. Attachez vos ceintures, ça va chauffer !

Rate Limiting vs Throttling : Quelle est la différence ?

Bien que ces termes soient souvent confondus, il existe une frontière claire entre eux :

\n
• Rate Limiting — c'est un blocage « strict ». Si un utilisateur dépasse la limite (par exemple, 100 requêtes par minute), le serveur renvoie HTTP 429 (Too Many Requests). Les requêtes n'atteignent tout simplement pas la logique métier.
\n
• Throttling — c'est un ralentissement « doux ». Le serveur accepte la requête, mais la traite avec un délai ou réduit sa priorité. L'utilisateur ne reçoit pas d'erreur, mais sa vitesse de travail diminue.
\n

En C#, nous pouvons implémenter les deux approches, souvent en les combinant pour différents scénarios.

Algorithmes de Rate Limiting : Du simple au complexe

Avant d'écrire du code, comprenons les mathématiques. Il existe quatre algorithmes « en or » qui sont à la base de 90 % des solutions.

1. Fixed Window (Fenêtre fixe)

La méthode la plus simple. Nous divisons le temps en intervalles fixes (par exemple, 1 minute) et comptons les requêtes dans chaque fenêtre. Dès que le compteur atteint la limite — nous bloquons.

Avantages : Simplicité d'implémentation. Inconvénients : Problème d'« effet de bord » (burst lors du passage entre les fenêtres).

public class FixedWindowRateLimiter\n{\n    private readonly int _limit;\n    private readonly TimeSpan _windowSize;\n    private int _counter;\n    private DateTime _windowStart;\n\n    public FixedWindowRateLimiter(int limit, TimeSpan windowSize)\n    {\n        _limit = limit;\n        _windowSize = windowSize;\n        _windowStart = DateTime.UtcNow;\n    }\n\n    public bool AllowRequest()\n    {\n        var now = DateTime.UtcNow;\n        if (now - _windowStart >= _windowSize)\n        {\n            // Réinitialisation de la fenêtre\n            _counter = 0;\n            _windowStart = now;\n        }\n\n        if (_counter >= _limit)\n            return false; // Too Many Requests\n\n        Interlocked.Increment(ref _counter);\n        return true;\n    }\n}

2. Sliding Window (Fenêtre glissante)

Une évolution de Fixed Window. Au lieu de limites rigides, nous prenons en compte les requêtes dans un intervalle de temps glissant. Généralement implémenté via la journalisation des horodatages (par exemple, dans un tampon circulaire).

Avantages : Lisse les pics. Inconvénients : Légèrement plus complexe à implémenter, nécessite de la mémoire pour stocker les horodatages.

public class SlidingWindowRateLimiter\n{\n    private readonly int _limit;\n    private readonly TimeSpan _windowSize;\n    private readonly Queue<DateTime> _timestamps = new();\n\n    public SlidingWindowRateLimiter(int limit, TimeSpan windowSize)\n    {\n        _limit = limit;\n        _windowSize = windowSize;\n    }\n\n    public bool AllowRequest()\n    {\n        var now = DateTime.UtcNow;\n        lock (_timestamps)\n        {\n            // Suppression des horodatages obsolètes\n            while (_timestamps.Count > 0 && now - _timestamps.Peek() > _windowSize)\n                _timestamps.Dequeue();\n\n            if (_timestamps.Count >= _limit)\n                return false;\n\n            _timestamps.Enqueue(now);\n            return true