Sujet : system-design
-
Étude de cas d'un service de téléversement de fichiers : tickets directs vers le stockage, analyse asynchrone et quotas
Une étude de conception pour des téléversements qui contournent les serveurs d'application : un ticket qui réserve un quota et renvoie une URL de téléversement signée, une étape de finalisation qui vérifie l'objet stocké, un worker d'analyse qui le promeut ou le supprime, des règles de cycle de vie pour les téléversements abandonnés, et un modèle de statut qui explique chaque objet stocké.
-
Étude de cas d'un service de notification : canaux, préférences, tentatives de livraison et nouvelles tentatives
Une étude de conception pour un service de notification multicanal : une API d'ingestion avec une clé d'idempotence, un routeur qui déploie une notification en livraisons par canal après vérification des préférences, des files d'attente et des calendriers de nouvelles tentatives par canal, la gestion des callbacks pour les jetons invalides, et ce qu'il faut différer.
-
Les services de liens courts à identifiants séquentiels reçoivent plus de requêtes d'énumération que ceux à identifiants aléatoires
Hypothèse : un raccourcisseur d'URL dont les clés sont un compteur encodé en base62 permet à quiconque de parcourir tous les liens, alors que des clés aléatoires de longueur fixe font échouer la plupart des essais ; la proposition est que les services séquentiels voient une part plus élevée de requêtes portant sur des clés existantes émises par des clients qui n'ont jamais reçu le lien, et que la part de réponses 404 ne permet pas à elle seule de distinguer les deux cas.
-
Parcours de conception d'un raccourcisseur d'URL : génération de clés, statut de redirection et contrôles d'abus
Un parcours de conception pour un raccourcisseur d'URL : des clés base62 aléatoires avec nouvelle tentative en cas de collision, un chemin de redirection touchant un seul cache et un seul stockage, 302 plutôt que 301 lorsque les cibles doivent rester révocables et comptables, des contrôles d'abus côté création, et une liste de ce qu'il ne faut pas construire en premier.
-
Parcours de conception d'un ordonnanceur de tâches : baux, nouvelles tentatives, clés d'idempotence et table de file
Un parcours de conception pour les tâches de fond et les planifications récurrentes sur une table de base de données : les workers réclament des lignes avec FOR UPDATE SKIP LOCKED sous un bail, les échecs replanifient avec un backoff jusqu'à un maximum, une clé d'idempotence unique transforme les doubles mises en file en no-op, et un broker de messages est différé jusqu'à ce que l'âge de la file dise le contraire.
-
Recherche documentaire sur un corpus : parcours de conception du pipeline d'indexation, des permissions et de la réindexation
Un parcours de conception pour la recherche sur des documents conservés dans un système de référence (system of record) : un index dérivé et reconstructible alimenté par des événements de changement, des clés d'ACL indexées comme des champs pour que le filtrage ait lieu avant le classement, des index versionnés basculés via un alias, un réconciliateur qui détecte les dérives, et une liste de ce qu'il faut différer.
-
Parcours d'un classement : événements de score, ensemble trié dérivé et classements reconstructibles
Un parcours de conception pour les classements : des événements de score faisant autorité côté serveur, avec une clé d'idempotence, comme source de vérité ; un ensemble trié par période de classement, comme index dérivé, répondant aux requêtes de top N et de rang d'un seul membre ; des règles d'égalité codées dans le score ; des limites de période acheminées par l'heure de survenue ; et des reconstructions traitées comme une routine.
-
À quel moment les équipes remplacent-elles une table de file d'attente PostgreSQL par un courtier de messages, et qu'est-ce qui a déclenché ce passage ?
Question ouverte : la documentation PostgreSQL avalise l'usage de SKIP LOCKED pour plusieurs consommateurs sur une table faisant office de file d'attente, et les présentations de conception de ce wiki recommandent de commencer ainsi ; quels déclencheurs (âge de la file, contention de verrous, gonflement de la table, besoins de diffusion à plusieurs destinataires, charge opérationnelle) ont effectivement provoqué un passage à un courtier, à quels volumes, et combien de systèmes n'ont jamais changé ?
-
Anatomie d'un magasin de sessions : identifiants opaques, deux expirations, révocation et comportement en cas de panne
Une présentation détaillée de la conception du magasin côté serveur derrière un cookie de session : des lignes indexées par un hachage de l'identifiant, une expiration par inactivité et une expiration absolue configurables, des écritures de dernière activité limitées en fréquence, un index par utilisateur pour la déconnexion globale, un comportement « fail-closed » en cas de panne du magasin, et des fonctionnalités à reporter.
-
Présentation d'un service de feature flags : ensembles de règles, évaluation locale et déploiements progressifs stables en pourcentage
Présentation de la conception d'un service de flags : les définitions de flags sont servies sous la forme d'un ensemble de règles versionné par environnement, des SDK mettent en cache et évaluent localement, un contexte d'évaluation sert au ciblage, un regroupement par hachage stable évite qu'un utilisateur bascule pendant un déploiement progressif, des valeurs pré-évaluées sont fournies aux clients non fiables, et un rapport permet de repérer les flags morts.
-
Parcours d'un service de configuration : versions immuables, déploiement par étapes et dernier état bon connu
Un parcours de conception pour distribuer une configuration à l'exécution : des versions immuables et validées ; un contrôleur de déploiement qui fait avancer, par étapes, des cohortes choisies par un hachage stable, avec un délai de maintien et une condition d'arrêt ; des clients qui interrogent ou observent, appliquent de façon atomique et conservent un fichier de dernier état bon connu ; et ce qui est délibérément laissé de côté.
-
Comment system walk-through: threads, moderation states and re-renderable content
A design walk-through for threaded comments with moderation: source text stored as truth and rendered through a patched sanitiser at read time, a materialised path with a depth cap, pending/visible/hidden/removed states that keep thread shape, a report and moderation-action audit, and features deliberately left for later.
Lisible par machine : JSON