Skalierbare Systeme für morgen.

Wachstum konkret beschreiben

„Das System muss skalieren“ ist noch keine prüfbare Anforderung. Beschreiben Sie stattdessen erwartete Last und notwendige Reaktionszeiten. Wie viele Vorgänge treten gleichzeitig auf? Wie groß sind die Daten? Gibt es kurze Spitzen oder gleichmäßige Nutzung? Welche Aufgaben dürfen im Hintergrund laufen?

Ein Bestellvorgang, ein Datenimport und eine Berichtserstellung haben unterschiedliche Anforderungen. Wer alles gleich behandelt, optimiert möglicherweise die falsche Stelle. Legen Sie deshalb fest, welche Nutzerabläufe kritisch sind und wie sich eine Überlastung dort bemerkbar machen würde.

Klare Grenzen statt unnötiger Verteilung

Ein gut strukturierter gemeinsamer Anwendungsserver kann für viele Vorhaben ein sinnvoller Anfang sein. Wichtig ist, fachliche Bereiche und ihre Zuständigkeiten nachvollziehbar zu trennen. Werden Module sauber geschnitten, lassen sie sich später leichter unabhängig verändern.

Eine Aufteilung in viele Dienste bringt zusätzliche Aufgaben mit sich: Netzwerkfehler, verteilte Fehlersuche und unterschiedliche Datenstände müssen beherrscht werden. Entscheidend ist deshalb nicht die Anzahl der Dienste. Die Architektur sollte die Probleme lösen, die tatsächlich bestehen oder plausibel zu erwarten sind.

Schnittstellen und Hintergrundaufgaben planen

Schnittstellen brauchen verständliche Verträge: Welche Daten werden erwartet? Welche Antwort bedeutet Erfolg? Was passiert bei Zeitüberschreitung oder wiederholtem Aufruf? Besonders bei Buchungen und anderen Schreibvorgängen muss verhindert werden, dass ein erneuter Versuch denselben Vorgang ungewollt mehrfach ausführt.

Längere Aufgaben lassen sich häufig über eine Warteschlange vom direkten Nutzeraufruf trennen. Asynchrone Kommunikation kann Komponenten entkoppeln und Lastspitzen abfedern; Microsoft beschreibt dafür verschiedene Messaging-Muster. Sie ersetzt aber keine Planung für Rückstände, fehlerhafte Nachrichten oder mehrfach zugestellte Ereignisse.

Weiterführend: Microsoft: Asynchronous messaging options ↗

Engpässe messen, bevor man umbaut

Oft liegt eine Grenze an einer konkreten Stelle: einer langsamen Datenbankabfrage, einer externen Schnittstelle oder einer Aufgabe, die unnötig oft ausgeführt wird. Lasttests mit realistischen Abläufen helfen, diese Grenzen sichtbar zu machen. Eine reine Zahl gleichzeitiger Verbindungen sagt wenig über einen vollständigen Geschäftsprozess aus.

Erfassen Sie Antwortzeiten, Fehlerraten und Auslastung im Zusammenhang. Protokolle sollten einen Vorgang über seine Stationen nachvollziehbar machen, ohne unnötig vertrauliche Inhalte mitzuschreiben. So lässt sich unterscheiden, ob mehr Rechenleistung hilft oder ein fachlicher Ablauf verändert werden muss.

Ausfälle als Teil des Betriebs behandeln

Auch ein gut geplantes System kann ausfallen. Legen Sie fest, wer eine Störung bemerkt, wie sie eingegrenzt wird und wie ein vorheriger funktionsfähiger Stand wiederhergestellt werden kann. Backups sind erst dann belastbar, wenn eine Wiederherstellung praktisch geprüft wurde.

Skalierbarkeit hat außerdem eine wirtschaftliche Seite. Mehr Infrastruktur verursacht Kosten und zusätzlichen Betriebsaufwand. Prüfen Sie daher bei jeder Ausbauentscheidung, welche konkrete Lastgrenze verschoben wird und wie sich das auf laufende Kosten und Wartbarkeit auswirkt.

• Last, kritische Abläufe und Reaktionszeiten konkret festlegen.
• Verantwortlichkeiten und Schnittstellen verständlich halten.
• Engpässe unter realistischer Last messen.
• Überwachung, Wiederherstellung und Kosten gemeinsam betrachten.