prasoonsoni/system-design-studio

---

name: system-design-studio description: Créez un guide de conception système de niveau senior (HLD) pour tout produit ou entreprise : exigences, capacité, diagrammes d'architecture et ER, schéma, API et compromis, en thèmes clair et sombre.

System Design Studio

À utiliser lorsque l'utilisateur demande de concevoir, expliquer ou apprendre la conception de haut niveau (HLD) d'un système : "concevoir Uber", "conception système de Netflix", "HLD pour une passerelle de paiement", "concevoir un réducteur d'URL", "préparation d'entretien pour concevoir X". Le livrable est un document HTML autonome et navigable, publié comme artefact, avec modes clair et sombre, et optionnellement un canevas interactif. Lorsque l'utilisateur souhaite un fichier à exécuter localement, livrez le guide et le canevas sous forme d'une seule page HTML avec des onglets (§9).

Les exemples de référence dans ce dépôt montrent la barre de qualité : examples/stock-broker/ (thème par défaut, guide et canevas en pages séparées) et examples/uber/ (thème produit, SVG d'architecture dessiné à la main, guide et canevas dans un seul fichier).

1. Déterminer le sujet et le thème

Classez d'abord la demande. Cela détermine à la fois l'angle du contenu et l'apparence.

• Produit ou entreprise nommé(e) (Uber, Netflix, WhatsApp, Swiggy, Zerodha, Airbnb, Spotify, Stripe, Instagram, ...) : le guide est "Conception système de " et est thématisé selon l'univers de ce produit (voir §5.2). Utilisez le vocabulaire du domaine de l'entreprise partout (Uber : passagers, conducteurs, courses, répartition, tarification dynamique, ETA ; Netflix : titres, lecture, CDN, échelle d'encodage ; WhatsApp : discussions, accusés de réception, dernière vue).
• Système générique (réducteur d'URL, application de chat, passerelle de paiement, limiteur de débit, service de notification, "une application de covoiturage" sans nom d'entreprise) ou un produit obscur que vous ne pouvez pas situer : utilisez le thème modèle par défaut (§5.1).
• L'utilisateur nomme un style ("faites-le ressembler aux docs de Stripe", "simple et minimal") : suivez cela plutôt que les deux règles ci-dessus.

Pour une entreprise nommée, faites des recherches avant de concevoir : lancez des recherches web sur ses articles de blog d'ingénierie publics et ses présentations (par exemple Uber : index géospatial H3, Ringpop, Schemaless, Cadence ; Netflix : Open Connect, EVCache, Zuul). Utilisez ce qui est public, marquez-le comme tel ("selon le blog d'ingénierie d'Uber"), listez les sources dans le pied de page du guide, et étiquetez tout le reste comme une hypothèse. Ne présentez jamais une conception déduite comme l'architecture interne réelle de l'entreprise.

2. Réfléchir avant de construire

Avant d'écrire du HTML, élaborez (et indiquez dans un court message à l'utilisateur) :

• L'aperçu fondamental du domaine : la limite ou l'idée qui, si elle est manquée, rend toute la conception erronée. Exemples : "le courtier achemine, la bourse apparie" ; "une passerelle de paiement ne détient jamais de fonds, l'acquéreur le fait" ; "la répartition d'Uber est un problème d'appariement géospatial sous un budget de latence de quelques secondes". Placez-le dans la vue d'ensemble sous forme d'appel.
• Les plans : quels chemins nécessitent une forte cohérence (argent, commandes, inventaire, réservations → CP) et lesquels privilégient la disponibilité (flux, recherche, présence, pings de localisation, analyses → AP). Séparez-les à la périphérie.
• Les problèmes difficiles : idempotence, ordonnancement, diffusion, clés chaudes, partitionnement géographique, rapprochement, revendications exactly-once.
• Périmètre inclus / exclu (ce qui est traité comme une intégration externe).
• La décision de thème du §1 : quel thème produit, ou le défaut.

Si la demande est vraiment ambiguë (quel produit ? profondeur d'entretien vs profondeur de production ?), posez une question ; sinon, commencez.

3. Sections requises (numérotées, dans cet ordre)

1. Vue d'ensemble : ce qu'est le système, appel d'aperçu fondamental, listes des éléments inclus / exclus.
2. Exigences : tableau fonctionnel (domaine → capacités, utilisant le vocabulaire réel du domaine et les énumérations) et tableau non fonctionnel (attribut → cible → notes). Incluez toujours la latence, la disponibilité, la cohérence (CP/AP par chemin), la durabilité, l'évolutivité, la sécurité, l'idempotence.
3. Estimation de capacité : tableau d'hypothèse → nombre dérivé (utilisateurs, DAU, concurrence maximale, écritures/s moyenne ET maximale, lectures/s, sortie de diffusion, stockage/jour). Montrez l'arithmétique pour qu'elle puisse être vérifiée ; terminez par un appel de conclusion sur l'axe sur lequel chaque plan évolue. Pour une entreprise réelle, ancrez-vous sur son échelle publiquement rapportée si disponible et citez-la.
4. Architecture : un diagramme rendu (voir §6) plus du texte pour chaque plan et le backbone d'événements.
5. Analyses approfondies des composants : pour chaque service central : responsabilité, comment il fonctionne mécaniquement (machines d'état, protocoles, algorithmes), données possédées, gestion des pannes.
6. Cycle de vie du flux principal : le flux de bout en bout phare du produit (Uber : demander une course → appariement → course ; Netflix : appuyer sur Lecture → diffuser ; WhatsApp : envoyer un message → livré → lu) sous forme de tableau d'étapes (#, étape, propriétaire, état/événement), plus un appel sur les limites synchrones vs asynchrones.
7. Modèle de données et schéma : un diagramme ER/classe (voir §6), puis les magasins non relationnels (motifs de clés de cache, disposition de séries temporelles, index géographique, index de recherche), puis les sujets d'événements (sujet, clé de partition, événements) avec un exemple d'événement JSON. Ne DÉVERSEZ PAS de DDL SQL brut comme vue principale du schéma.
8. Conception API : tableau des conventions (auth, idempotence, enveloppe d'erreur, limites de débit, pagination, versionnement), tableau des points d'accès avec pastilles de méthode colorées, un couple requête/réponse travaillé pour l'écriture clé (montrant la sémantique des codes de statut, par exemple 202 pour asynchrone), tableau des codes de statut, et le protocole de streaming (WebSocket/SSE/gRPC stream) s'il y en a.
9. Cohérence et fiabilité : où chaque garantie s'applique, sagas + compensations, couches d'idempotence, tableau des scénarios de panne.
10. Évolutivité et performance : clés de sharding, mise à l'échelle automatique sans état, partitionnement, mise en cache, gestion des pics.
11. Sécurité et conformité : authn/z, protection des données, conservation réglementaire, protection contre les abus.
12. Observabilité : métriques clés, traçage, tableaux de bord de rapprochement, alertes.
13. Compromis : tableau décision → choix & pourquoi, se terminant par un appel "si vous vous souvenez de cinq choses".

4. Barre de précision (vérifier avant de publier)

• Chaque nombre dans la capacité est dérivé d'hypothèses énoncées et est cohérent en interne (multiplicateur moyenne vs pic indiqué).
• Chaque composant dans le diagramme d'architecture apparaît dans les analyses approfondies ou le flux, et vice versa.
• Chaque entité dans le diagramme ER est utilisée par un flux ou une API ; chaque chemin d'écriture d'une API touche une entité réelle.
• Les sujets Kafka/queue dans la section schéma correspondent aux étiquettes de bords dans le diagramme d'architecture.
• L'argent est modélisé comme un grand livre en partie double là où l'argent existe ; les clés d'idempotence apparaissent dans le schéma (contrainte unique) ET dans l'API (en-tête).
• Utilisez la terminologie réelle du domaine (types d'ordres, protocoles comme FIX/ISO 8583, réglementations) et dites quand quelque chose est une hypothèse.
• Pour une entreprise nommée : chaque affirmation sur sa pile réelle est sourcée ; tout le reste est marqué comme supposé.
• Ne prétendez jamais vrai exactly-once ; décrivez l'idempotence + le rapprochement.

5. Thèmes, mode clair et mode sombre

Chaque guide est livré avec les modes clair ET sombre : il suit le réglage système du lecteur par défaut, et un bouton de bascule dans l'en-tête le remplace (mémorisé par navigateur). Chargez la compétence artifact-design avant d'écrire la page.

5.0 Système de jetons (les deux modes)

Toutes les couleurs sont des propriétés personnalisées CSS. Ne codez jamais en dur une couleur dans une règle, un SVG ou un diagramme ; utilisez toujours un jeton. Définissez les valeurs claires sur :root, puis les valeurs sombres deux fois (préférence système à moins que le lecteur ait choisi clair, et le choix sombre explicite) :

:root{ color-scheme:light; /* jetons clairs */ }
@media (prefers-color-scheme: dark){
  :root:not([data-theme="light"]){ color-scheme:dark; /* jetons sombres */ }
}
:root[data-theme="dark"]{ color-scheme:dark; /* jetons sombres, répétés */ }
body{ background:var(--bg); color:var(--ink); }

Rôles de jetons requis (chaque thème définit tous les suivants, dans les deux modes). Utilisez des valeurs hexadécimales simples (pas de rgba(...)), car le rendu de diagramme se divise sur les virgules :

Jeton	Rôle
--bg, --surface, --surface-2, --line, --line-soft	page, cartes, cartes surélevées, bordures
--ink, --ink-mid, --ink-dim	titres/texte fort, corps, légendes
--accent, --accent-ink	la couleur signature du thème, et le texte dessiné dessus
--svc, --svc-bg	services dans les diagrammes
--bus, --bus-bg	file d'attente / bus d'événements
--ext, --ext-bg	systèmes externes
--store, --store-bg	magasins de données
--ok, --warn, --danger, --info	appels, pastilles de méthode, pastilles CP/AP
--code-bg, --code-ink, --code-key, --code-str, --code-num, --code-com	blocs de code
--font-display, --font-body, --font-mono	familles de polices

Contraste : texte du corps (--ink-mid sur --bg et --surface) au moins 4,5:1 dans les deux modes ; texte d'accent sur --surface au moins 4,5:1. Un accent vif qui fonctionne sur sombre a généralement besoin d'une nuance plus foncée pour le mode clair, alors choisissez les valeurs de chaque mode séparément plutôt que de les réutiliser.

Placez ceci dans <head> avant la feuille de style, pour qu'un choix enregistré s'applique sans flash :

<script>
(function(){var t=null;try{t=localStorage.getItem('sdg-theme')}catch(e){}
if(t==='light'||t==='dark')document.documentElement.dataset.theme=t;})();
</script>

Bouton de bascule dans l'en-tête (<button class="theme-toggle" id="themeToggle" aria-label="Changer le thème de couleur"></button>) et son script près de la fin de <body> :

<script>
(function(){
  var root=document.documentElement, mq=matchMedia('(prefers-color-scheme: dark)');
  function current(){return root.dataset.theme||(mq.matches?'dark':'light');}
  function label(){var b=document.getElementById('themeToggle');if(b)b.textContent=current()==='dark'?'☀ Claire':'☾ Sombre';}
  document.getElementById('themeToggle').addEventListener('click',function(){
    var next=current()==='dark'?'light':'dark';root.dataset.theme=next;
    try{localStorage.setItem('sdg-theme',next)}catch(e){}
    label();document.dispatchEvent(new Event('themechange'));});
  mq.addEventListener('change',function(){if(!root.dataset.theme){label();document.dispatchEvent(new Event('themechange'));}});
  label();
})();
</script>

5.1 Thème modèle par défaut (systèmes génériques)

Le style maison pour tout ce qui n'est pas lié à un produit nommé :

• Police : Space Grotesk (affichage), Inter (corps), JetBrains Mono (identifiants, énumérations, sujets, chemins).
• Sombre : base minuit. --bg #0a0e17, --surface #141b2c, --surface-2 #1a2336, --line #28324e, --ink #eaf0fb, --ink-mid #aab6d2, --ink-dim #7a86a4, --accent #5ec7df, --svc #4fd0e0/--svc-bg #152036, --bus #f3ab54/--bus-bg #241d12, --ext #fb7f95/--ext-bg #2a1622, --store #93a3c0/--store-bg #131b2c.
• Clair : papier froid. --bg #f6f8fc, --surface #ffffff, --surface-2 #eef2f8, --line #d6deea, --ink #0f1729, --ink-mid #45536b, --ink-dim #5f6c85, --accent #0b7287, --svc #0b7287/--svc-bg #e3f3f7, --bus #a35a00/--bus-bg #fdf0dd, --ext #b4234a/--ext-bg #fde7ec, --store #55627a/--store-bg #eef1f6.
• Mise en page : héros (sourcil, titre, résumé d'un paragraphe avec l'aperçu fondamental, 4 cartes TL;DR : échelle maximale, connexions, chemin CP, chemin AP), puis un corps à deux colonnes avec une table des matières collante et scrollspy sur ordinateur et un tiroir flottant "☰ Contenu" sur mobile.

5.2 Thèmes produit (entreprise nommée)

La page doit sembler appartenir à l'univers de ce produit, tout en restant clairement une étude indépendante. Déduisez un ensemble complet de jetons (les deux modes) du caractère visuel public du produit : sa palette, son humeur typographique, son langage de formes (angulaire vs arrondi), sa densité, et un motif signature. Points de départ (approximatifs, évoquez plutôt que copiez) :

Produit	Direction de palette	Police (substitut gratuit)	Forme et motif
Uber	Noir et blanc monochrome, un accent vert	Inter Tight, graisses d'affichage lourdes	Coins angulaires, haut contraste ; lignes de routes de carte et points de prise en charge/dépose
Netflix	Presque noir avec un accent rouge profond ; mode clair blanc chaud + rouge	Bebas Neue affichage, Inter corps	Grands titres cinématographiques, rangées de cartes d'affiches
WhatsApp	Vert sarcelle sur neutre doux ; mode sombre vert-gris profond	Inter / UI système	Appels de bulle de chat, marques de statut à double coche
Airbnb	Blanc chaud avec accent corail	Nunito Sans	Arrondi généreux, ombres douces, espacement amical
Spotify	Noir avec vert vif ; mode clair blanc + vert	Figtree ou DM Sans	Boutons en pastille, motif de forme d'onde/barre de progression
Stripe	Clair d'abord, accents indigo/violet, dégradés doux	Inter	Lignes fines et nettes, blocs de code comme éléments de première classe
Swiggy / Zomato	Orange chaud ou rouge sur crème ; brun-noir foncé	Poppins	Cartes arrondies, chronologie de suivi de commande
Zerodha	Blanc propre avec accent bleu ; ardoise foncée	Inter	Tableaux de données denses, bande de ticker

Pour une entreprise non listée dans le tableau, appliquez la même méthode : identifiez sa couleur signature, son humeur et son motif, puis construisez les deux modes.

Garde-fous pour les thèmes produit :

• Inspiré par, jamais copié. Pas de logos, de marques nominatives, d'icônes d'application, de mascottes, de captures d'écran ou d'écrans d'interface utilisateur copiés, et pas de polices propriétaires (Uber Move, Netflix Sans, Circular, Cereal) : utilisez les substituts gratuits. Le motif est dessiné de manière générique (une ligne de route, une bulle de chat), pas repris du produit.
• Titrez-le comme une étude : "Conception système d'Uber" ou "Concevoir une plateforme de covoiturage à l'échelle d'Uber", jamais comme si Uber l'avait publié.
• Pied de page, toujours : "Étude éducative indépendante. Non affiliée ou approuvée par . Architecture reconstruite à partir de sources publiques et d'hypothèses énoncées." plus la liste des sources.
• Les diagrammes, tableaux, appels et pastilles utilisent toujours la même structure de composants que le modèle par défaut, recolorés via les jetons. Le thème produit change l'apparence, pas la structure en 13 sections.

5.3 Composants partagés

• Tableaux dans des enveloppes de défilement arrondies ; appels (clé / avertir / info / note) avec une barre latérale colorée ; pastilles de méthode (GET --ok, POST --info, PUT --warn, DELETE --danger) ; pastilles CP/AP.
• Blocs de code uniquement pour les charges utiles JSON, les motifs de clés et les messages de protocole, avec une barre d'en-tête indiquant le langage ou le point d'accès et des couleurs de syntaxe provenant des jetons --code-*.
• Largeur téléphone

...

(Le contenu original a été tronqué pour la traduction ; la version complète est conservée dans la compétence traduite.)