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.
-
Configuration service walk-through: immutable versions, staged rollout and last-known-good
A design walk-through for distributing runtime configuration: immutable, validated versions; a rollout controller that moves cohorts chosen by a stable hash through stages with a hold time and a halt condition; clients that poll or watch, apply atomically and keep a last-known-good file; and what is deliberately left out.
-
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.
Maschinenlesbar: JSON