Thema: system-design
-
Durchgang durch einen Datei-Upload-Dienst: Tickets direkt zum Speicher, asynchrones Scannen und Kontingente
Ein Design-Durchgang für Uploads, die an den Anwendungsservern vorbeigehen: ein Ticket, das Kontingent reserviert und eine signierte Upload-URL zurückgibt, ein Abschlussschritt, der das gespeicherte Objekt verifiziert, ein Scan-Worker, der es freigibt oder löscht, Lebenszyklusregeln für abgebrochene Uploads sowie ein Statusmodell, das jedes gespeicherte Objekt erklärt.
-
Durchgang durch einen Benachrichtigungsdienst: Kanäle, Präferenzen, Zustellversuche und Wiederholungen
Ein Entwurfsdurchgang für einen mehrkanaligen Benachrichtigungsdienst: eine Ingest-API mit Idempotenzschlüssel, ein Router, der nach Prüfung der Präferenzen eine Benachrichtigung in Zustellungen je Kanal auffächert, Warteschlangen und Wiederholungspläne pro Kanal, Callback-Verarbeitung für ungültige Tokens und was zurückgestellt werden sollte.
-
Kurzlink-Dienste mit fortlaufenden Kennungen erhalten mehr Enumerationsanfragen als Dienste mit zufälligen Kennungen
Hypothese: Ein URL-Verkürzer, dessen Schlüssel ein in Base62 codierter Zähler sind, erlaubt es jedem, sämtliche Links der Reihe nach durchzugehen, während zufällige Schlüssel fester Länge die meisten Rateversuche ins Leere laufen lassen; die These lautet, dass Dienste mit fortlaufenden Schlüsseln einen höheren Anteil an Anfragen für bestehende Schlüssel von Clients sehen, die den Link nie erhalten haben, und dass der Anteil an 404-Antworten allein die beiden Fälle nicht unterscheidet.
-
URL-Shortener im Durchgang: Schlüsselerzeugung, Weiterleitungsstatus und Missbrauchskontrollen
Ein Entwurfsdurchgang für einen URL-Shortener: zufällige Base62-Schlüssel mit Kollisionswiederholung, ein Weiterleitungspfad, der genau einen Cache und einen Speicher berührt, 302 statt 301, wenn Ziele widerrufbar und zählbar bleiben müssen, Missbrauchsprüfungen bei der Erstellung, und eine Liste dessen, was zuerst nicht gebaut werden sollte.
-
Job-Scheduler im Durchgang: Leases, Wiederholungen, Idempotenzschlüssel und eine Queue-Tabelle
Ein Design-Durchgang für Hintergrundjobs und wiederkehrende Zeitpläne auf einer Datenbanktabelle: Worker beanspruchen Zeilen mit FOR UPDATE SKIP LOCKED unter einer Lease, Fehlschläge planen mit Backoff bis zu einem Maximum neu ein, ein eindeutiger Idempotenzschlüssel macht doppelte Einreihungen zu No-ops, und ein Message Broker wird zurückgestellt, bis das Alter der Queue etwas anderes nahelegt.
-
Dokumentensuche über einen Korpus im Überblick: Indexierungs-Pipeline, Berechtigungen und Reindexierung
Ein Design-Überblick für die Suche über Dokumente in einem führenden System: ein abgeleiteter, neu erstellbarer Index, gespeist von Änderungsereignissen, ACL-Schlüssel als indexierte Felder, sodass Filterung vor dem Ranking stattfindet, versionierte Indizes, die per Alias umgeschaltet werden, ein Abgleicher, der Drift findet, und eine Liste dessen, was zurückgestellt wird.
-
Leaderboard-Walkthrough: Score-Events, ein abgeleitetes Sorted Set und rekonstruierbare Ranglisten
Ein Design-Walkthrough für Ranglisten (Leaderboards): serverautoritative Score-Events mit Idempotenzschlüssel als Wahrheitsquelle, je ein Sorted Set pro Board-Periode als abgeleiteter Index für Top-N- und Einzelrang-Abfragen, in den Score codierte Regeln für Gleichstände, nach Ereigniszeitpunkt geroutete Periodengrenzen, und Rebuilds als Routineaufgabe.
-
An welchem Punkt ersetzen Teams eine PostgreSQL-Queue-Tabelle durch einen Message Broker, und was löste den Wechsel aus?
Offene Frage: Die PostgreSQL-Dokumentation billigt SKIP LOCKED für mehrere Konsumenten auf einer warteschlangenartigen Tabelle, und Design-Durchgänge empfehlen, dort zu beginnen; welche Auslöser (Alter der Warteschlange, Sperrkonkurrenz, Tabellen-Bloat, Fan-out-Bedarf, Betriebsaufwand) haben tatsächlich einen Wechsel zu einem Broker verursacht, bei welchen Volumina, und wie viele Systeme haben nie gewechselt?
-
Session-Store im Durchgang: opake IDs, zwei Ablaufzeiten, Widerruf und Verhalten bei Ausfall
Ein Entwurfsdurchgang für den serverseitigen Store hinter einem Session-Cookie: Zeilen, die über einen Hash der ID indexiert sind, Ablaufzeiten für Inaktivität und absolute Dauer als Konfiguration, gedrosselte Schreibvorgänge für den letzten Zugriffszeitpunkt, ein Benutzerindex für das Abmelden auf allen Geräten, Fail-Closed-Verhalten bei einem Ausfall des Stores, und Funktionen, die zurückgestellt werden.
-
Feature-Flag-Dienst im Detail: Regelwerke, lokale Auswertung und stabile Prozent-Rollouts
Ein Design-Durchgang für einen Flag-Dienst: Flag-Definitionen, ausgeliefert als ein versioniertes Regelwerk pro Umgebung, SDKs, die lokal cachen und auswerten, ein Auswertungskontext fürs Targeting, Bucketing über einen stabilen Hash, damit Nutzer während eines Rollouts nie wechseln, vorab ausgewertete Werte für nicht vertrauenswürdige Clients sowie ein Reporting, das tote Flags findet.
-
Konfigurationsdienst im Durchgang: unveränderliche Versionen, gestufter Rollout und Last-Known-Good
Ein Entwurfsdurchgang für die Verteilung von Laufzeitkonfiguration: unveränderliche, validierte Versionen; ein Rollout-Controller, der über einen stabilen Hash gewählte Kohorten durch Stufen mit Haltezeit und Abbruchbedingung bewegt; Clients, die pollen oder beobachten, atomar anwenden und eine Last-Known-Good-Datei führen; und was bewusst weggelassen wird.
-
Durchgang durch ein Kommentarsystem: Threads, Moderationszustände und neu rendbarer Inhalt
Ein Design-Durchgang für Kommentar-Threads mit Moderation: Quelltext als massgebliche Wahrheit gespeichert und beim Lesen über einen gepatchten Sanitizer gerendert, ein materialisierter Pfad mit Tiefenbegrenzung, Zustände pending/visible/hidden/removed, die die Thread-Form erhalten, eine Prüfspur für Meldungen und Moderationsaktionen, sowie Funktionen, die absichtlich für später zurückgestellt wurden.
Maschinenlesbar: JSON