Latency-Critical Systems Playbook

Sélectionné par Skill Harbor : un guide d'ingénierie qui fait traiter à Muse la latence comme un ensemble de quantités séparées et mesurables au lieu d'un vague « rapide ». Le skill sépare les métriques : latences p50, p95 et p99, débit, âge de fraîcheur, profondeur de file, taux de hit du cache, temps de réponse du fournisseur, temps de rendu navigateur, correction sous charge, et comportement d'échec/retry. Puis il cartographie le chemin critique de l'événement source à l'état visible par l'utilisateur (événement source, API fournisseur, worker d'ingestion, file, cache, route edge, flux client, rendu navigateur) et mesure chaque segment séparément, pour que l'effort d'optimisation frappe là où le temps part vraiment. L'ordre d'optimisation est strict : supprimer d'abord les allers-retours inutiles, mettre en cache les lectures stables avec métadonnées de fraîcheur, grouper les petits appels, rapprocher le calcul des données ou de l'utilisateur, séparer chemins chauds et froids, appliquer la contre-pression avant que les files ne croissent sans borne, n'utiliser le streaming que s'il améliore la fraîcheur, ajouter des canaris pour données périmées et fournisseurs dégradés. La vérification utilise des lectures réelles contre la surface déployée : timings et en-têtes HTTP, horodatages de fraîcheur du fournisseur, état des files et du edge, vérification navigateur de la fraîcheur réelle de l'UI, logs autour des retries et du mode dégradé. Garde-fous stricts : ne jamais optimiser la latence en supprimant une validation requise, ne jamais masquer des données périmées derrière des hits de cache rapides, ne jamais revendiquer un comportement milliseconde depuis des labels client sans mesure, ne jamais lancer d'ordres réels, de migrations destructrices ou de déploiements impactant les clients sans porte d'approbation explicite, et garder les secrets hors des logs et artefacts de benchmark. Par @affaan-m, listé ici avec crédit à son créateur. Tiré du dépôt affaan-m/ECC (MIT). Bémols honnêtes : c'est un guide d'ingénierie qui n'autorise ni trading réel ni conseil financier ; pour les chemins proches des données de marché ou de l'exécution, vérifiez l'âge du carnet d'ordres, les hypothèses VWAP, le statut du fournisseur et le comportement du coupe-circuit avant de déclarer le chemin prêt. Skill Harbor ne vérifie jamais le code, examinez-le vous-même avant usage.