Microservices

Was sind Microservices?

Microservices sind ein Architekturansatz, bei dem eine Anwendung aus kleinen, fachlich abgegrenzten und unabhängig betreibbaren Diensten besteht. Jeder Dienst übernimmt eine klar definierte Aufgabe, kommuniziert über Schnittstellen mit anderen Diensten und lässt sich separat entwickeln, bereitstellen und skalieren. Das erleichtert Änderungen, erhöht jedoch die technische und organisatorische Komplexität.

Microservices zerlegen eine umfangreiche Software in kleine, unabhängig betreibbare Dienste. Die deutsche Entsprechung lautet Mikrodienste. Statt Produktverwaltung, Suche, Warenkorb, Bezahlung und Benutzerkonten in einer gemeinsamen Anwendung zu bündeln, kann jede Funktion als eigener Dienst umgesetzt werden.

Wie funktionieren Microservices?

Jeder Microservice bildet einen abgegrenzten fachlichen Bereich ab. Ein Shopsystem kann beispielsweise einen Dienst für Produkte, einen für Preise und einen für Bestellungen verwenden. Die Dienste kommunizieren meist über Programmierschnittstellen, sogenannte APIs. Eine API legt fest, welche Daten ein Dienst annehmen oder ausgeben kann.

Die fachliche Trennung ist wichtiger als die reine Größe. Ein Dienst mit wenigen Codezeilen ist noch kein sinnvoller Microservice, wenn jede Änderung gleichzeitig Anpassungen an fünf anderen Diensten verlangt. Gute Servicegrenzen orientieren sich an eigenständigen Geschäftsprozessen und klaren Zuständigkeiten.

Produktdienst: verwaltet Artikelnummern, Beschreibungen und Eigenschaften.
Preisservice: liefert Preise, Rabatte und kundenspezifische Konditionen.
Suchdienst: verarbeitet Suchanfragen und Filter.
Bestelldienst: übernimmt Warenkorb, Bestellung und Bestellstatus.
Inhaltsdienst: stellt redaktionelle Texte, Bilder und Metadaten bereit.

Microservices werden üblicherweise separat bereitgestellt. Ein Fehler im Suchdienst kann dadurch behoben werden, ohne gleichzeitig den Bestellprozess neu zu veröffentlichen. Diese Unabhängigkeit funktioniert jedoch nur, wenn Schnittstellen stabil sind, Abhängigkeiten dokumentiert werden und jeder Dienst automatisiert getestet werden kann.

Ein Onlineshop kann Produktdaten aus einem Product Information Management System, Preise aus einem Warenwirtschaftssystem und redaktionelle Inhalte aus einem CMS beziehen. Die sichtbare Produktseite entsteht erst, wenn das Frontend diese Daten zusammenführt. Fällt eine Schnittstelle aus, muss eine definierte Ersatzdarstellung verhindern, dass eine leere oder fehlerhafte Seite ausgeliefert wird.

Microservices in CMS und Shopsystemen

Bei CMS und Shopsystemen ermöglichen Microservices eine modulare Systemlandschaft. Das CMS verwaltet Inhalte, während separate Dienste beispielsweise Suche, Personalisierung, Produktdaten, Zahlungen oder Kundenkonten übernehmen. Unternehmen können einzelne Komponenten austauschen, ohne die gesamte Plattform neu aufzubauen.

Ein Headless CMS trennt die Inhaltsverwaltung von der Darstellung. Inhalte werden über eine API an Websites, Apps oder andere Ausgabekanäle geliefert. Ein Headless CMS ist deshalb nicht automatisch eine Microservices-Architektur: Die Trennung zwischen Backend und Frontend beschreibt zunächst nur den Bereitstellungsansatz. Erst mehrere eigenständig entwickelte und betriebene Dienste bilden eine entsprechende Architektur.

Im E-Commerce eignet sich der Ansatz vor allem für umfangreiche Sortimente, mehrere Länder, unterschiedliche Frontends oder häufig wechselnde Geschäftslogik. Ein kleiner Shop mit überschaubaren Anforderungen profitiert dagegen oft stärker von einem integrierten System. Microservices erzeugen zusätzlichen Aufwand für Schnittstellen, Hosting, Tests, Rechteverwaltung und Überwachung.

Bei der Auswahl einer Architektur sollten Unternehmen deshalb nicht nur Funktionslisten vergleichen. Relevant sind die Zahl der angebundenen Systeme, die Änderungshäufigkeit, interne Entwicklungsressourcen und die Folgen eines Ausfalls. Die SEO-Anforderungen von Onlineshops sollten bereits in diese technische Planung einfließen.

Microservices und monolithische Systeme

Der Unterschied zwischen Microservices und einem Monolithen liegt in der technischen Kopplung. Bei einem Monolithen laufen viele Funktionen in einer gemeinsamen Anwendung und werden meist zusammen bereitgestellt. Microservices besitzen dagegen getrennte Laufzeitumgebungen und definierte Kommunikationswege.

Merkmal	Microservices	Monolith
Bereitstellung	Dienste können einzeln veröffentlicht werden	Die Anwendung wird meist als Einheit veröffentlicht
Skalierung	Einzelne stark genutzte Funktionen lassen sich gezielt erweitern	Häufig wird die gesamte Anwendung skaliert
Fehlersuche	Erfordert zentrale Protokolle und verteiltes Monitoring	Fehler lassen sich innerhalb einer Anwendung verfolgen
Datenhaltung	Dienste können getrennte Datenmodelle besitzen	Eine gemeinsame Datenbank ist verbreitet
Änderungen	Klare Servicegrenzen erlauben unabhängige Releases	Änderungen können einen gemeinsamen Release erfordern

Ein Monolith ist nicht grundsätzlich veraltet oder ungeeignet. Für kleinere Anwendungen bietet eine gemeinsame Codebasis oft kürzere Kommunikationswege und weniger Betriebsaufwand. Microservices liefern ihren Vorteil erst dann, wenn voneinander unabhängige Funktionen tatsächlich unterschiedlich entwickelt, veröffentlicht oder skaliert werden müssen.

Welche Vorteile bieten Microservices?

Microservices begrenzen Änderungen auf einen fachlichen Bereich. Ein Unternehmen kann beispielsweise die Produktsuche überarbeiten, während Warenkorb und Zahlung unverändert weiterlaufen. Voraussetzung ist, dass der neue Suchdienst dieselben vereinbarten Schnittstellen unterstützt oder die API-Version kontrolliert geändert wird.

Einzelne Funktionen lassen sich getrennt entwickeln und bereitstellen.
Rechenleistung kann gezielt für stark belastete Dienste erhöht werden.
Teams können fachlich abgegrenzte Komponenten eigenständig verantworten.
Einzelne Technologien lassen sich passend zur Aufgabe auswählen.
Fehler können auf einen Dienst begrenzt bleiben, wenn Rückfallmechanismen vorhanden sind.

Technologische Freiheit ist zugleich eine mögliche Kostenquelle. Wenn jeder Dienst eine andere Programmiersprache, Datenbank oder Protokollform verwendet, steigen Wartungsaufwand und Wissensbedarf. Verbindliche Standards für Schnittstellen, Protokollierung, Sicherheit und Bereitstellung halten die Systemlandschaft beherrschbar.

Risiken verteilter Architekturen

Microservices ersetzen interne Funktionsaufrufe durch Netzwerkkommunikation. Jeder zusätzliche Aufruf kann scheitern, verzögert beantwortet werden oder veraltete Daten liefern. Besonders kritisch sind Abhängigkeitsketten: Benötigt eine Produktseite nacheinander Daten aus fünf Diensten, kann bereits ein langsamer Dienst die gesamte Ausgabe verzögern.

Eine weitere Herausforderung ist die Datenkonsistenz. Wenn Bestellung, Lagerbestand und Zahlung getrennt verarbeitet werden, erfolgen Aktualisierungen nicht zwingend im selben Moment. Die Architektur muss festlegen, wie fehlgeschlagene Vorgänge wiederholt, zurückgesetzt oder fachlich ausgeglichen werden.

Die Anzahl der Dienste ist kein Qualitätsmerkmal. Werden Funktionen zu früh oder zu kleinteilig getrennt, entstehen zahlreiche Schnittstellen und schwer nachvollziehbare Abhängigkeiten. Prüfe vor jeder Aufteilung, ob der neue Dienst einen eigenständigen Geschäftsprozess besitzt und unabhängig veröffentlicht werden muss.

SEO bei Microservices prüfen

Microservices sind kein direkter Ranking-Faktor. Für SEO zählt das Ergebnis, das Suchmaschinen abrufen und rendern können. Eine technisch modulare Plattform kann gute Rankings erreichen, wenn sie vollständiges HTML, stabile URLs, korrekte Statuscodes, konsistente Canonical Tags und aktuelle XML-Sitemaps ausliefert.

Bei Headless-Shops entsteht ein konkretes Risiko, wenn relevante Inhalte erst nach mehreren clientseitigen API-Aufrufen erscheinen. Fehlen Produktname, Beschreibung, interne Links oder strukturierte Daten im gerenderten Ergebnis, erhält die Suchmaschine eine unvollständige Seite. Serverseitiges Rendering oder statisch erzeugte Seiten können die benötigten Inhalte bereits mit der ersten HTML-Antwort bereitstellen.

Messbar ist das zum Beispiel so: Prüfe für zentrale Seitentypen den HTTP-Status, die Serverantwortzeit, das gerenderte HTML, Canonical Tags, interne Links und strukturierte Daten. Vergleiche zusätzlich, ob Produktpreise, Verfügbarkeit und Inhaltsversionen im Browser und im abrufbaren Quelltext übereinstimmen. Ein technischer SEO-Audit sollte dabei nicht nur einzelne URLs, sondern auch die beteiligten Schnittstellen und Vorlagen untersuchen.

Auswirkungen auf SEA und GEO

Für SEA beeinflusst eine Microservices-Architektur vor allem die Zuverlässigkeit der Landingpages und des Trackings. Wenn Preisservice, Formular oder Warenkorb nicht erreichbar sind, kann bezahlter Traffic auf unvollständigen Seiten landen. Statusüberwachung und automatisierte Tests sollten deshalb auch zentrale Conversion-Schritte abdecken.

Für GEO, also Generative Engine Optimization, müssen öffentlich erreichbare Inhalte eindeutig und konsistent sein. Wenn Produktmerkmale, Unternehmensdaten oder Leistungsbeschreibungen aus mehreren Diensten stammen, dürfen die ausgegebenen Informationen einander nicht widersprechen. Klare Seitenstrukturen und verlässliche Entitäten erleichtern Suchmaschinen und KI-Systemen die Einordnung.

Ein geplanter Plattformwechsel benötigt deshalb eine gemeinsame Prüfung von Architektur und Auffindbarkeit. Die SEO-Checkliste für einen Website-Relaunch hilft dabei, Weiterleitungen, Indexierung und technische Signale vor dem Livegang abzusichern.

Häufige Fragen zu Microservices

Wann lohnen sich Microservices für einen Onlineshop?

Microservices lohnen sich vor allem bei komplexen Shops mit mehreren Frontends, Ländern, Datenquellen oder häufig veränderten Geschäftsprozessen. Für kleine Shops kann ein integriertes Shopsystem wirtschaftlicher und leichter zu betreiben sein.

Sind Microservices dasselbe wie Headless Commerce?

Nein. Headless Commerce trennt das Frontend von der Handelsplattform. Microservices teilen die fachlichen Funktionen zusätzlich in unabhängig betreibbare Dienste auf. Beide Ansätze können kombiniert werden, setzen einander aber nicht voraus.

Braucht jeder Microservice eine eigene Datenbank?

Eine getrennte Datenhaltung unterstützt die Unabhängigkeit der Dienste, ist aber keine zwingende technische Vorgabe. Eine gemeinsam genutzte Datenbank koppelt Dienste enger, weil Änderungen am Datenmodell mehrere Komponenten gleichzeitig betreffen können.

Welche Schnittstellen nutzen Microservices?

Microservices kommunizieren häufig über HTTP-basierte APIs oder asynchrone Nachrichtensysteme. Die Wahl hängt davon ab, ob eine Antwort unmittelbar benötigt wird oder ein Vorgang zeitversetzt verarbeitet werden kann.

Sind Microservices automatisch schneller?

Nein. Zusätzliche Netzwerkaufrufe können die Antwortzeit erhöhen. Eine Microservices-Architektur wird erst durch Caching, kurze Abhängigkeitsketten, stabile Schnittstellen und passende Skalierung leistungsfähig.

Wie lassen sich Microservices testen?

Neben Tests einzelner Dienste sind Schnittstellen-, Integrations- und End-to-End-Tests erforderlich. Besonders wichtig sind Tests für Ausfälle, Zeitüberschreitungen, fehlerhafte Daten und ältere API-Versionen.

Wenn du eine modulare CMS- oder Shoparchitektur planst, sollte SEO bereits vor der technischen Umsetzung berücksichtigt werden. Ein kostenloser Potenzialcheck ordnet die Anforderungen deiner Plattform unverbindlich ein.

Kostenlosen Potenzialcheck anfragen

Sie haben noch Fragen?

Kontaktieren Sie uns