Skalierbare IT-Architektur: Systeme bauen, die mit dem Unternehmen wachsen

Skalierbarkeit entscheidet sich nicht bei der Serverbestellung, sondern in der Architektur: Ob ein System mit dem Unternehmen mitwächst, hängt davon ab, wie seine Bestandteile miteinander sprechen und wo der Zustand liegt. Wer das früh richtig anlegt, kauft später Rechenleistung dazu; wer es falsch anlegt, baut später neu.

Was ein skalierbares IT-Rückgrat im Mittelstand wirklich braucht

Die meisten mittelständischen Systeme scheitern nicht an der Datenmenge, sondern an der Verflechtung. Ein Warenwirtschaftssystem, eine Zeiterfassung, ein Kundenportal und ein paar Excel-Dateien, die zwischen ihnen vermitteln: Das ist der Normalfall, den wir in IT-Abteilungen ohne eigene Entwickler antreffen. Jedes einzelne Werkzeug käme mit dem Wachstum zurecht. Was nicht mitwächst, sind die Übergaben dazwischen, weil sie von Hand laufen oder an einem nächtlichen Skript hängen, das niemand mehr anfassen will.

Ein skalierbares Rückgrat heißt deshalb zuerst: klare Zuständigkeiten je System und saubere Schnittstellen zwischen ihnen. Die Datenhaltung muss Wachstum aushalten. Erst danach kommt die Frage nach mehr Servern.

Horizontale Skalierung setzt zustandslose Dienste voraus

Horizontal skalieren heißt, weitere Instanzen eines Dienstes nebeneinander zu stellen, statt einen einzelnen Server immer größer zu kaufen. Das funktioniert nur, wenn jede Anfrage unabhängig von der vorherigen bearbeitet werden kann. Sitzungsdaten im Arbeitsspeicher eines Servers oder Dateien auf der lokalen Platte binden Nutzer an eine bestimmte Maschine und machen die zweite Instanz nutzlos.

Vertikale Skalierung ist deshalb nicht falsch. Für viele Bestandssysteme ist ein größerer Server der günstigste Schritt, und er verschafft Zeit. Er ist nur endlich, und die Grenze kommt meist in dem Moment, in dem sie am wenigsten passt.

Die Datenbank: PostgreSQL trägt weiter, als viele glauben

Die Datenbank ist in gewachsenen Systemen der häufigste Engpass, aber selten, weil sie zu klein wäre. Meist fehlen Indizes, Abfragen holen ganze Tabellen statt der benötigten Spalten, oder dieselben Daten liegen in mehreren Systemen und werden nachts abgeglichen. Eine sauber betriebene PostgreSQL-Datenbank mit Lesereplikaten bewältigt die Datenmengen fast aller mittelständischen Unternehmen, ohne dass Sie Ihre Daten auf mehrere Knoten aufteilen müssen.

Sharding, also das Aufteilen der Daten nach Kunde oder Region auf getrennte Datenbanken, lohnt sich erst, wenn Messwerte es verlangen. Es macht jede Auswertung über alle Kunden hinweg aufwendig und jede Migration riskanter. Unsere Position: Wer im Mittelstand mit Sharding beginnt, löst ein Problem, das er nicht hat, und schafft sich eines, das er behält.

Caching hält die Antwortzeit konstant

Ein Zwischenspeicher im Arbeitsspeicher, etwa Redis, nimmt der Datenbank die Anfragen ab, die sich ständig wiederholen: Produktkataloge, Stammdaten oder Berechtigungen. Die Antwortzeit bleibt dann auch unter Last gleichmäßig. Der Preis ist die Frage, wann ein gespeicherter Wert veraltet ist. Wer sie nicht beantwortet, zeigt Kunden gestrichene Preise oder gelöschte Artikel. Legen Sie deshalb für jede zwischengespeicherte Datenart fest, welches Ereignis sie ungültig macht, bevor der Cache in Betrieb geht.

Asynchrone Verarbeitung entkoppelt Spitzenlast

Nicht jede Aufgabe muss erledigt sein, während der Nutzer wartet. Rechnungen erzeugen oder Berichte berechnen: Solche Arbeiten gehören in eine Warteschlange, die von eigenen Arbeitsprozessen abgearbeitet wird. Kommt eine Lastspitze, wächst die Warteschlange, statt dass die Oberfläche einfriert. Werkzeuge wie RabbitMQ oder Apache Kafka leisten das. Für viele Anwendungen reicht auch eine Tabelle in der bestehenden Datenbank als Warteschlange, bis die Last etwas anderes verlangt.

Mehrere Systeme über REST API verbinden statt Daten zu kopieren

Schnittstellen entscheiden darüber, ob ein Rückgrat wächst oder wuchert. Jeder Dienst stellt eine klar beschriebene, versionierte REST-API bereit, und andere Systeme lesen und schreiben ausschließlich über sie. Damit hört das nächtliche Kopieren auf, jeder Datensatz hat einen Ort, an dem er stimmt, und ein Dienst lässt sich austauschen oder skalieren, ohne dass die anderen es merken.

Versionierung ist dabei kein Komfort, sondern die Bedingung dafür, dass Sie eine Schnittstelle ändern können, während ein Altsystem noch die alte Fassung nutzt. Altsysteme ohne API bekommen einen schmalen Adapter vorgeschaltet, der ihre Datenbank oder ihre Exportdateien liest und nach außen sauber anbietet. Wie das in der Praxis aussieht, zeigt der Artikel Legacy-ERP modernisieren: mehrere Systeme über REST API verbinden.

Ohne Messwerte skalieren Sie blind

Monitoring gehört zur Architektur, nicht zum Nachtrag. Erfassen Sie Antwortzeiten je Endpunkt, Datenbanklatenz, Speicher und Auslastung, mit Werkzeugen wie Prometheus und Grafana oder mit dem, was Ihr Hoster mitbringt. Erst diese Zahlen sagen Ihnen, welcher der genannten Schritte als Nächstes dran ist. Automatische Skalierung, die bei Last neue Instanzen startet, ist dann der letzte Baustein, nicht der erste: Sie setzt zustandslose Dienste und eine Datenbank voraus, die die Last trägt.

Der nächste Schritt: den Engpass benennen, bevor Sie ihn spüren

Nehmen Sie das System, das Ihnen bei Wachstum die meisten Sorgen macht, und beantworten Sie zwei Fragen: Wo liegt der Zustand, und wer kopiert Daten von Hand hinein oder heraus? Wenn die Antwort ein Skript, eine Excel-Datei oder eine Person ist, haben Sie Ihren Engpass. Eine halbe Stunde reicht: Wir gehen Ihre Antwort gemeinsam durch und sagen Ihnen, welcher Schritt sich zuerst lohnt und ob wir dafür die Richtigen sind: Potenzial-Check buchen.