Aller au contenu principal

Limites, quotas et performance

État actuel des limites côté API B2B et recommandations pour maintenir la performance sous charge.

1. État actuel​

L'API B2B n'expose pas aujourd'hui de rate-limit serveur standardisé :

  • Pas d'en-tête X-RateLimit-* sur les réponses.
  • Pas de réponse 429 Too Many Requests systématique.
  • Pas de limites publiées par endpoint.

En pratique, les limites sont implicites :

  • Timeouts ASP.NET Core côté serveur (120s par défaut).
  • Concurrence côté DB (pool de connexions EF Core).
  • Bande passante réseau entre MCM et votre infrastructure.

2. Bornes opérationnelles observées​

Ces bornes sont empiriques — testées en staging/prod mais non garanties contractuellement. Vérifiez avec votre contact MCM pour vos cas de charge exceptionnelle.

OpérationVolume testé sans dégradationCommentaire
ISyncClient.Sync~10 000 employés / appelAvec emplois imbriqués. Au-delà, découper en lots
IVotantsClient.MettreAJourDroitsDeVote40 000+ IDs / appelOptimisé pour grands volumes
IEmployesClient.UpdateCourriels~5 000 entrées / appelValidation par entrée
ISignatureClient.SearchSignaturesV2~100 000 résultats retournésPréférer fenêtre glissante au-delà
GetAll* (employeurs, syndicats, formulaires)≤ 1 000 entitésSans pagination — à utiliser avec parcimonie

3. Recommandations de parallélisme​

Appels unitaires en rafale​

await Parallel.ForEachAsync(
    items,
    new ParallelOptions
    {
        MaxDegreeOfParallelism = 10,           // 5-10 = sweet spot
        CancellationToken = ct
    },
    async (item, innerCt) =>
    {
        await client.UpsertVotant(campagneId, item);
    });
  • MaxDegreeOfParallelism = 10 est une bonne valeur par défaut.
  • Au-delà de 20, vous risquez de saturer le pool de connexions HTTP de votre côté (HttpClient partagé) et la DB côté MCM.
  • Surveillez la latence P95 par appel. Si elle augmente > 2× sous charge, baissez le parallélisme.

Appels bulk​

Un seul appel gras > N appels fins. Priorisez toujours :

  1. ISyncClient.Sync pour les employés (plutôt que AddEmploye en boucle).
  2. IVotantsClient.MettreAJourDroitsDeVote pour les droits de vote en lot (plutôt que IListeElectoraleClient.MettreAJourDroitDeVote unitaire).
  3. SearchSignaturesV2 avec filtres riches (plutôt que GetSignaturesV2ParIdExterne pour chaque membre).

4. Taille des charges utiles​

Sérialisation​

  • JSON UTF-8, pas de compression automatique côté client (activable via HttpClient middleware).
  • Pas de limite maximale explicite côté serveur, mais ASP.NET Core plafonne par défaut à ~30 Mo par requête.

Estimation​

1 employé B2BUpsertEmployeDtoV2 avec 2 emplois + 1 adhésion ≈ 1.5 KB JSON
10 000 employés ≈ 15 MB JSON → dans la limite

Au-delà, découpez en lots de 5 000 ou utilisez la compression gzip (MCM accepte Content-Encoding: gzip).

5. Stratégies pour la haute volumétrie​

Import initial (1M+ employés)​

  1. Créer d'abord tous les syndicats et employeurs (ensemble petit, stable).
  2. Découper les employés en fichiers de 10 000.
  3. Boucler sur les fichiers avec un Sync par fichier, séquentiel (pas en parallèle — sinon contention DB côté MCM).
  4. Logger les B2BSyncResult.Erreurs pour les corrections ultérieures.
  5. Garder un état local (LastBatchFinished) pour reprendre en cas d'interruption.

Sync incrémental (quotidien)​

  1. Récupérer LastSyncedAt depuis votre stockage.
  2. Extraire les employés modifiés depuis LastSyncedAt.
  3. Sync en un seul appel (ou 2-3 lots) — rarement > 1 000 employés par jour.
  4. Persister le nouveau LastSyncedAt après succès complet.

Analyse / export (adhésions, consentements)​

Fenêtre temporelle glissante — voir search-and-filtering.md §4.

6. Observabilité et alerting​

À instrumenter côté consommateur :

MétriqueSeuil d'alerte
Taux d'erreur 5xx sur B2B> 1 % sur 5 min
Latence P95 par endpoint2× baseline sur 10 min
Taux de 429 (futur)> 0.5 %
Taille moyenne payload Sync> 20 MB (signe d'un batch trop gros)
Durée totale Sync> 3 min (découper si possible)

Exemple Serilog + OpenTelemetry :

using var activity = ActivitySource.StartActivity("mcm.sync");
activity?.SetTag("mcm.employes.count", employes.Count);

var sw = Stopwatch.StartNew();
var result = await syncClient.Sync(syndicats, employes, []);
activity?.SetTag("mcm.sync.durationMs", sw.ElapsedMilliseconds);

if (result.IsError)
{
    activity?.SetStatus(ActivityStatusCode.Error, result.FirstError.Description);
    logger.LogError("MCM Sync failed: {Code}", result.FirstError.Code);
}

7. Que faire en cas de dégradation côté MCM​

  1. Baisser le parallélisme (de 10 à 5, voire 1 — séquentiel).
  2. Augmenter l'intervalle entre lots (1s → 5s entre appels).
  3. Activer le retry exponentiel — voir idempotency.md §2.
  4. Contacter MCM avec :
    • Timestamp UTC du début de dégradation.
    • Endpoint concerné (POST b2b/v2/employe/Sync).
    • Volume / payload moyen.
    • Codes d'erreur observés.
  5. Dégradation contrôlée de votre côté : si MCM est indisponible, mettez le sync en file d'attente plutôt que de perdre les événements.

8. Évolutions prévues​

Cette section sera mise à jour quand MCM introduira des limites de débit explicites. À ce moment-là, ce guide exposera :

  • Quotas par endpoint et par clé API.
  • Format des en-têtes X-RateLimit-Remaining / X-RateLimit-Reset.
  • Politique de 429 + Retry-After.

En attendant, les recommandations ci-dessus sont les meilleures pratiques.

Voir aussi​