Rate Limiting

L'API MyTelevision applique un rate limiting par profil (et non par compte) pour proteger la plateforme et garantir une qualite de service equitable. Le rate limiting est base sur Redis et est distribue (cluster-safe).

Limites par defaut

L'API utilise trois tiers de rate limiting :

Tier	Limite	Fenetre	Utilisation
Short	3 requetes	1 seconde	Endpoints sensibles (login, register)
Medium	20 requetes	10 secondes	Endpoints d'ecriture (POST, PATCH, DELETE)
Long	100 requetes	1 minute	Endpoints de lecture (GET)

Limites par categorie d'endpoint

Categorie	Tier	Limite	Details
POST /auth/login	Short	5 tentatives / 15 min	Anti brute-force
POST /auth/register	Short	3 req / 1 sec	Anti-spam
POST /auth/refresh	Medium	20 req / 10 sec	Refresh token
GET /movies, GET /series	Long	100 req / 1 min	Lecture de contenu
POST /reactions	Medium	20 req / 10 sec	Engagement
POST /views	Medium	20 req / 10 sec	Tracking de vues
POST /signals	Specifique	60 req / 1 min	Signaux unitaires
POST /signals/batch	Specifique	10 req / 1 min	Signaux en batch
POST /streaming/token	Medium	20 req / 10 sec	Tokens de streaming
POST /account/2fa/verify-2fa	Specifique	5 req / 1 min	Verification 2FA
Endpoints de lecture generaux	Long	100 req / 1 min	Tous les GET

Headers de reponse

Chaque reponse de l'API inclut des headers de rate limiting :

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1702800000

Header	Description
X-RateLimit-Limit	Nombre total de requetes autorisees dans la fenetre
X-RateLimit-Remaining	Nombre de requetes restantes
X-RateLimit-Reset	Timestamp UNIX de la reinitialisation du compteur

En cas de depassement (429)

Quand la limite est atteinte, l'API retourne un code 429 Too Many Requests avec le header supplementaire :

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1702800060

{
  "statusCode": 429,
  "message": "Rate limit exceeded",
  "error": "Too Many Requests"
}

Cle de rate limiting

Le rate limiting est applique par combinaison de :

(tenant_id, profile_id, tier)

Important

Le rate limiting est par profil et non par compte. Changer de profil, de device ou de session ne permet pas de contourner les limites.

Bonnes pratiques

Implementer un retry avec backoff exponentiel

async function fetchWithRetry(url: string, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await api.get(url);
    } catch (error) {
      if (error.response?.status === 429) {
        const retryAfter = error.response.headers['retry-after'];
        const delay = retryAfter
          ? parseInt(retryAfter) * 1000
          : Math.pow(2, i) * 1000;
        await new Promise((resolve) => setTimeout(resolve, delay));
      } else {
        throw error;
      }
    }
  }
  throw new Error('Max retries exceeded');
}

Surveiller les headers

function checkRateLimit(response: AxiosResponse) {
  const remaining = parseInt(response.headers['x-ratelimit-remaining']);
  const limit = parseInt(response.headers['x-ratelimit-limit']);

  if (remaining < limit * 0.1) {
    console.warn(`Rate limit warning: ${remaining}/${limit} remaining`);
  }
}

Strategies de reduction des appels

1. Mise en cache cote client -- Cacher les reponses qui changent peu (genres, categories, plans)
2. Batching -- Utiliser les endpoints batch quand disponibles (POST /signals/batch)
3. Debouncing -- Limiter les appels sur les champs de recherche
4. Pagination raisonnable -- Ne pas demander plus de 50 items par page
5. Conditional requests -- Utiliser les headers If-None-Match / If-Modified-Since quand supportes