Start / Methoden & Systeme / RegTech Engineering Podcast

RegTech Engineering Podcast

Titelbild zur beitrag: RegTech Engineering Podcast
RegTech Engineering · Podcast-Skript · Episode 11
🎙  Offizielles Podcast-Skript  ·  Staffel 3, Episode 11
RegTechEngineering
Die Engpässe der Programmiergeschichte — und das eine Muster, das sie alle löst
Laufzeit
ca. 45 Min.
Akte
7 + Shownotes
Niveau
Intermediate
Besetzung
RUTH
Ruth de Lucha — Tech-Historikerin. Zieht Verbindungen zwischen Dekaden, die niemand sonst sieht. Ist überzeugt, dass wer die Geschichte kennt, die Zukunft antizipieren kann.
FRANZ-JOSEF
Franz-Josef van der Jagd — Pragmatischer Backend-Entwickler mit 20 Jahren Erfahrung. Hinterfragt alles, liebt konkrete Beispiele, hat wenig Geduld für Theorie ohne Praxis.
Act 1
Der Einstieg: Fortran und das RAM-Limit der 70er
Intro-Jingle, langsam ausblendend. Modem-Geräusch als Easter Egg für aufmerksame Hörerinnen.
RUTH
Willkommen zu RegTech Engineering! Heute nehmen wir euch mit auf eine Reise durch 50 Jahre Programmiergeschichte. Und ich verspreche: Am Ende werdet ihr euren Code nie wieder mit denselben Augen anschauen.
FRANZ-JOSEF
Das klingt mal wieder sehr dramatisch, Ruth. Aber gut — ich bin dabei. Was ist das Thema heute?
RUTH
Engpässe. Jede Dekade hatte einen. Und ich behaupte: Es war immer derselbe Engpass — nur in neuem Kostüm.
FRANZ-JOSEF
Jetzt bin ich neugierig. Wann fangen wir an?
RUTH
1970. Fortran. Du sitzt vor einem Mainframe, der ein ganzes Zimmer füllt, und dein Programm darf nur wenige Kilobyte groß sein. Nicht Megabyte — Kilobyte.
FRANZ-JOSEF
Kilo-… Ich rede von Spring-Boot-Projekten, die beim Hochfahren 300 MB in den Heap saugen. Und die hatten Kilobyte?
RUTH
Exakt. Und das war keine rein technische Einschränkung — es hatte direkte wirtschaftliche Konsequenzen. Rechenzeit wurde nach Minuten abgerechnet. Jede unnötige Schleife kostete echtes Geld.
FRANZ-JOSEF
Und wie haben die Entwickler das gelöst?
RUTH
Mit Overlays. Du zerlegst das Programm in Segmente — nur das Segment, das gerade gebraucht wird, liegt im Speicher. Der Rest wartet auf der Disk.
FRANZ-JOSEF
Moment… Das klingt wie virtueller Speicher.
RUTH
Genau! Und das ist das erste Mal heute, dass du diesen Begriff hörst. Merke ihn dir — er kommt noch mindestens fünfmal.
Key Fact

Cooley-Tukey FFT (1965): Ein Algorithmus, der primär aus Ressourcenknappheit entstand — O(n log n) statt O(n²). Knappheit als Mutter der Erfindung.

Act 2
Die 80er: 640 KB und die Explosion der Komplexität
Kurze musikalische Überleitung — 8-Bit Melodie, 4 Sekunden.
RUTH
Weiter in die 80er. PCs kommen auf den Markt. MS-DOS. Und dann gibt es das berühmteste Limit der Computergeschichte: 640 Kilobyte RAM.
FRANZ-JOSEF
Ich kenne das Zitat. Hat Bill Gates wirklich gesagt, 640 KB seien für immer genug?
RUTH
Wahrscheinlich nicht — aber die Legende lebt, weil sie so perfekt zur damaligen Denkweise passt. Niemand konnte sich vorstellen, dass Programme jemals so groß werden könnten.
FRANZ-JOSEF
Und sie wurden es natürlich. Was war der neue Engpass?
RUTH
Gleich zwei Dinge auf einmal: Der Adressraum — du kannst nur 640 KB adressieren. Und gleichzeitig die kognitive Komplexität. Codebases wuchsen über das hinaus, was ein einzelner Entwickler im Kopf behalten konnte.
FRANZ-JOSEF
Das kenne ich aus eigener Erfahrung. Ich arbeite an einer Codebase, die seit 2008 gewachsen ist. Manchmal stehe ich vor einer Datei und denke: Wer hat das geschrieben, und warum existiert das Universum überhaupt?
RUTH
Ha! Und genau deswegen wurde Modularisierung erfunden. Pascal Units, C-Header-Dateien, frühe OOP. Das Prinzip: Verstecke Komplexität hinter einer sauberen Schnittstelle. Was sich ändert, soll sich intern ändern können — ohne dass der Rest des Systems etwas merkt.
FRANZ-JOSEF
Information Hiding. Lernt man noch heute im ersten Semester.
RUTH
Weil es funktioniert. Turbo Pascal war dafür ein Paradebeispiel: Interface-Teil für den Aufrufer, Implementation-Teil versteckt. Exakt wie eine moderne API.
Key Fact

Das Parnas-Prinzip (1972): Jedes Modul versteckt eine Designentscheidung. David Parnas formulierte es, bevor irgendjemand das Wort „Microservices“ kannte.

Act 3
Die 90er: Das Internet explodiert — die Leitung ist dünn
Modem-Einwahlgeräusch — das volle Erlebnis. Ca. 6 Sekunden, dann ausblenden.
FRANZ-JOSEF
90er. Das Internet kommt. Schöne Zeit, oder?
RUTH
Es war totales Chaos. Stell dir vor: Du willst eine Webseite bauen. Deine Nutzer haben 56-Kilobit-Modems. Jedes Bild über 20 Kilobyte ist eine Zumutung. Und gleichzeitig müssen Systeme in völlig verschiedenen Sprachen miteinander reden.
FRANZ-JOSEF
Zwei verschiedene Probleme gleichzeitig.
RUTH
Sind es auch. Aber beide haben dieselbe Lösung: Protokoll-Abstraktion. Du einigst dich auf ein gemeinsames Format — und dann ist es egal, ob der Server in C++ läuft und der Client in JavaScript. HTTP. XML. CGI. Das sind keine Technologien um der Technologie willen. Das sind Lösungen auf reale Engpässe.
FRANZ-JOSEF
CGI — ich hab mal Code gesehen, der noch CGI-Skripte hatte. Das war… erschreckend schön.
RUTH
Aber genial! CGI war das simpelste Interface, das man sich vorstellen kann. Server gibt Input über Umgebungsvariablen, das Skript schreibt HTML auf stdout, fertig. Kein Framework, keine Magie. Unix-Philosophie als Webserver.
FRANZ-JOSEF
Und JPEG, GIF — die dominierten auch diese Zeit, oder?
RUTH
Nicht weil sie technisch perfekt waren — sondern weil sie unter Bandbreitenknappheit funktionierten. Knappheit treibt Innovation. Immer.
Key Fact

Tim Berners-Lee erfand HTTP nicht als Plattform für Social Media — sondern damit Physiker am CERN schneller Dokumente teilen konnten. Der Engpass: Heterogene Systeme, die nicht miteinander reden konnten.

Act 4
Die 2000er: Millionen User, zustandslose Server
Kurze Pause. Tastaturgetacker im Hintergrund, dann Stille.
FRANZ-JOSEF
Ich fange an, das Muster zu sehen. Neue Knappheit, neue Abstraktion. Was kommt in den 2000ern?
RUTH
Die vielleicht gemeinste Knappheit von allen: Zustand. HTTP ist zustandslos — das ist kein Bug, das ist ein Feature. Aber Anwendungen sind nicht zustandslos. Ein Nutzer loggt sich ein, legt Dinge in den Warenkorb — und dein Server weiß davon nichts.
FRANZ-JOSEF
Sessions!
RUTH
Ja, und da beginnt das Problem. Wenn du eine Million Nutzer hast und jeder seinen Zustand in den Speicher eines Servers schreibt — was passiert, wenn der Server ausfällt?
FRANZ-JOSEF
Alle Sessions weg. Alle Nutzer fliegen raus. Ich kenne das aus dunklen Produktions-Nächten.
RUTH
Die Lösung: Externalisiere den Zustand. Memcached 2003, Redis 2009. Schreib ihn nicht in den Prozessspeicher — schreib ihn in einen Dienst, der unabhängig vom Webserver lebt.
FRANZ-JOSEF
Das… ist dasselbe wie die Overlays in den 70ern. Du lagerst das aus, was nicht reinpasst.
RUTH
Ding ding ding! Und Map-Reduce, 2004, Google: Petabytes an Daten, keine Maschine groß genug. Lösung: Zerlege das Problem in Teile, die auf tausenden kleinen Maschinen parallel laufen. Jede Maschine bearbeitet nur einen Chunk — kleiner als der Engpass.
FRANZ-JOSEF
Und damit schufen sie die Grundlage für Big Data, Hadoop, Spark und letztlich die gesamte Cloud-Architektur.
Key Fact

Amazon Web Services entstand 2006 — als internes Tooling wurde zum Produkt. Der Engpass: Amazon selbst brauchte skalierbare Infrastruktur. Die Lösung wurde zum größten Cloud-Anbieter der Welt.

Act 5
Die 2010er: Microservices und die Koordinations-Hölle
Leichtes Lachen von beiden nach einer kurzen Pause.
FRANZ-JOSEF
Ich war in den 2010ern mittendrin. Microservices. Ich erinnere mich, als das Wort aufkam — alle dachten: Endlich! Das löst alles!
RUTH
Und dann?
FRANZ-JOSEF
Dann hatten wir 80 Services, die miteinander reden mussten, und niemand wusste mehr, warum Service 34 Service 71 anruft. Und Service 71 manchmal einfach keine Lust hatte zu antworten.
RUTH
Klassisch. Der Engpass der 2010er war Koordination. Microservices lösten das Monolithen-Problem — zu viel Code in einem Topf — aber schufen ein neues: Wie hält man 200 kleine Dinge konsistent zusammen?
FRANZ-JOSEF
Kubernetes war die Antwort, oder?
RUTH
2014. Aber das Entscheidende ist nicht die Technologie — es ist das Prinzip: Deklarative Orchestrierung. Du sagst nicht mehr „Starte Container A, warte 30 Sekunden, starte B“. Du sagst: „Ich will drei Instanzen von Service X. Wenn eine stirbt, starte sie neu.“ Das System figurt den Weg selbst aus.
FRANZ-JOSEF
Wie React!
RUTH
Exakt! React 2013: Nicht mehr „manipuliere dieses DOM-Element“ — sondern „so soll die UI aussehen, gegeben diesen Zustand“. Terraform, Ansible — alles in dieser Ära. Ein Paradigmenwechsel von imperativ zu deklarativ.
FRANZ-JOSEF
Der Computer wird zum Orchestrator. Wir definieren das Ziel — er findet den Weg.
RUTH
Und das ist wichtig für die nächste Dekade. Weil dieser Gedanke noch viel weiter geht.
Key Fact

Netflix‘ Chaos Monkey: Ein Tool, das zufällig Server abschießt — um zu testen, ob das System sich selbst heilt. Der Engpass erzwingt Resilienz als Designprinzip.

Act 6
Die 2020er: Das Kontextfenster als neues 640-KB-Limit
Spannung in der Stimme — beide wissen, dass es jetzt ums Eingemachte geht.
FRANZ-JOSEF
Okay. Jetzt. 2020er. KI. Lass mich raten: neuer Engpass?
RUTH
Das Kontextfenster. Ein Large Language Model kann nur eine begrenzte Menge Text auf einmal „sehen“. Frühe Modelle: 4.000 Token. Heute: 128.000 oder mehr. Aber ein großes Codebase, ein langer Arbeitstag, ein mehrstündiges Gespräch — das passt immer noch nicht rein.
FRANZ-JOSEF
Das ist das 640-KB-Limit. Buchstäblich.
RUTH
Buchstäblich. Und es gibt noch ein zweites Problem: LLMs haben kein Gedächtnis zwischen Sessions. Du redest heute stundenlang mit einem Modell — morgen ist es, als hättet ihr euch nie getroffen.
FRANZ-JOSEF
Das kenne ich aus meiner täglichen Arbeit. Man erklärt den ganzen Kontext wieder und wieder — das ist Groundhog Day für Entwickler.
RUTH
Und genau hier entstehen gerade die Lösungen — in Echtzeit, während wir das aufnehmen. RAG: Retrieval-Augmented Generation. Du lagerst Wissen in einer Vektordatenbank aus. Wenn das Modell eine Frage bekommt, holt es sich nur die relevanten Chunks — genau die, die gerade gebraucht werden.
FRANZ-JOSEF
Lazy Loading für Wissen.
RUTH
Perfekt formuliert. Und MemGPT — ein System, das Kontext hierarchisch verwaltet wie ein Betriebssystem virtuellen Speicher. Working Memory, Episodic Memory, External Storage. Das Paper nennt es explizit: „LLMs as Operating Systems“.
FRANZ-JOSEF
Moment. Die lösen das Kontextfenster-Problem mit… Overlays. Wie in den 70ern.
RUTH
Fünfzig Jahre. Derselbe Engpass. Dieselbe Lösung. Anderer Name.
Key Fact

Agentic Systems: Ein LLM-Agent ist strukturell wie ein Microservice — zustandslos, klar definierte Inputs und Outputs, orchestriert von einem äußeren System. LangGraph und AutoGen sind das Kubernetes für KI-Agenten.

Act 7
Das Meta-Pattern — Ausblick — Abschluss
Ruhigere, nachdenklichere Atmosphäre. Beide sprechen langsamer.
FRANZ-JOSEF
Okay. Ich sehe das Muster. Aber formulier es für mich — in einem Satz.
RUTH
Jede Dekade: Eine Ressource ist knapp. Das System muss so tun, als wäre sie unbegrenzt verfügbar. Und jedes Mal wird dieselbe Lösung erfunden: eine Abstraktionsschicht, die nach außen Unbegrenztheit simuliert — und innen hierarchisch verwaltet, was tatsächlich verfügbar ist.
FRANZ-JOSEF
Virtualisierung.
RUTH
Exakt. Und es gibt drei Zutaten. Erstens: Zerlegung. Das Problem in Einheiten kleiner als der Engpass zerlegen. Zweitens: Hierarchisches Caching. Was häufig gebraucht wird, bleibt nah. Was selten gebraucht wird, lagert weit weg. Drittens: Lazy Evaluation. Lade nur, was gerade gebraucht wird.
FRANZ-JOSEF
Das ist so simpel, dass es fast unbefriedigend ist.
RUTH
Die besten Muster sind simpel. Das heißt nicht, dass die Implementierung einfach ist. Es bedeutet, dass das Prinzip klar ist.
FRANZ-JOSEF
Und was kommt als nächstes? Engpass der 2030er?
RUTH
Energie. KI-Inferenz ist teuer — nicht in Geld, sondern in Kilowattstunden. Wenn wir Milliarden Anfragen pro Tag haben, wird Energie die knappe Ressource. Und die Lösung? Wie immer: Smarter Cache von Modellausgaben. Kleinere spezialisierte Modelle für Standardaufgaben. Große Modelle nur wenn nötig. Lazy Inference.
FRANZ-JOSEF
Lazy Inference — das klingt wie ich vor meinem ersten Kaffee.
RUTH
Ha! Aber im Ernst: Wer das Meta-Pattern verstanden hat, wird jeden neuen Engpass antizipieren können — bevor er zur Krise wird. Das ist eine echte Superpower.
FRANZ-JOSEF
Programmiergeschichte als Superpower. Das hätte ich dem 22-jährigen Franz-Josef gerne gesagt.
Meta-Pattern

Simuliere Unbegrenztheit durch schichtweise Indirektion — zerlege in handhabbare Einheiten, cache das Häufige nah, lade das Seltene bei Bedarf. 1970 bis 2024. Immer dieselbe Antwort.

Musik setzt ein — Outro-Melodie, warm und etwas nostalgisch.
FRANZ-JOSEF
Das war RegTech Engineering. Ich bin Franz-Josef van der Jagd…
RUTH
…und ich bin Ruth de Lucha. Danke fürs Zuhören. Wenn euch diese Episode gefallen hat — teilt sie, bewertet uns, und schreibt uns: Was ist eurer Meinung nach der nächste große Engpass?
FRANZ-JOSEF
Den WordPress-Post zur Episode mit allen Dekaden, Codebeispielen und der Vergleichstabelle findet ihr in den Shownotes. Lohnt sich wirklich.
RUTH
Bis zur nächsten Episode — bleibt neugierig.
Outro-Jingle. Ende der Aufnahme.
Shownotes & Links
  • Cooley-Tukey FFT Algorithm — Original Paper (1965), Journal of Mathematics of Computation
  • David Parnas: „On the Criteria To Be Used in Decomposing Systems into Modules“ (1972), Communications of the ACM
  • Tim Berners-Lee: Original HTTP/HTML Proposal, CERN Internal Memo (1989)
  • Dean & Ghemawat: „MapReduce: Simplified Data Processing on Large Clusters“, Google (2004)
  • Netflix Tech Blog: Chaos Engineering Principles — chaos.engineering
  • MemGPT: „Towards LLMs as Operating Systems“ — Packer et al. (2023), arXiv:2310.08560
  • Kubernetes: Production-Grade Container Orchestration — kubernetes.io
  • „The Pragmatic Programmer“ — Hunt & Thomas: Kapitel zu Orthogonalität und DRY
Markiert: