Das erste Muster, das oft als Ausgangspunkt oder Gegenpol zu einer Microservices-Architektur gesehen wird, ist der Monolith. Wenn Microservices wachsen, kann es passieren, dass diese, falls keine weiteren Gegenmaßnahmen durchgeführt werden, schnell wieder in einem "kleinen Monolithen" münden. Die Muster lassen sich in die Bereiche Service-Discovery (Client-Side, Server-Side, Service Registry), Kommunikation (API Gateway), Deploymentarten (Mehrinstanzen oder Einzelinstanzen pro Host, Serviceinstanz pro VM oder Container) und Datenhaltung (separate Datenbank pro Service) aufteilen.

Bei den Diensten unterscheidet man zwischen Frontend- (Anwendung) und Backend-(Geschäftslogik) Services. Gerade wenn unterschiedliche Client-Arten, wie Webbrowser, native mobile Anwendungen oder Drittsysteme angebunden werden, ergeben sich unterschiedliche Anforderungen an Granularität, Formate oder Güte des genutzten Dienstes. Statt nur eine universelle Schnittstelle für alle Nutzer anzubieten, sollen spezifische Dienste angeboten werden. Damit Dienste sich nicht direkt kennen und aufrufen, wird eine Vermittlungskomponente benötigt.

Für die Umsetzung wird ein API-Gateway verwendet, als einheitlicher Endpunkt und Proxy für alle Clients. Für die Umsetzung können verschiedene Adapter oder Wrapper angeboten werden, um die eigentliche Implementierung von der Auslieferung zu trennen. Ebenso kann das Gateway sich um weitere Themen, wie Format- und Protokollumwandlung, Autorisierung, Authentifizierung oder Überwachung kümmern. Um die angeforderten, am besten passenden Dienste zu finden, gibt es zwei Arten der Dienstentdeckung auf der Client-Seite oder der Server-Seite. Beide Lösungen setzen voraus, dass sich Dienst-Instanzen selbst bei der Service-Registry an- und abmelden. Das gilt auch im Fehler- oder Überlastungsfall. Beispiele für solche Service-Registries sind Netflix Eureka oder Apache Zookeeper. Dieses Selbstregistrierungsmuster kann auch für die Verwendung von Funktionen von Drittanbietern verwendet werden. Ein gutes Beispiel dafür ist der Netflix OSS Eureka Client.

Die  Client-Seite benötigt eine zentrale Service-Registry, in der alle Dienste und ihre Orte verwaltet werden. Hier braucht der Client, der auch das API-Gateway sein kann, nur den entsprechenden Dienst anzufordern und erhält alle Informationen, um diesen aufzurufen. Gerade durch die hohe Anzahl und Dynamik, die mit Microservices verbunden ist, kann das ganze nur automatisch stattfinden. Anders als bei traditionellen Services sind die Orte (Host, Port) der aufgerufenen Dienste nicht fest, sondern können erst zur Laufzeit selbst ermittelt werden und ändern sich auch je nach Verfügbarkeit. Bei der Dienstentdeckung auf dem Server wird die Anfrage nicht an eine Service-Registry, sondern an einen Load-Balancer gestellt. Dieser dient auch als Router zum jeweiligen Dienst und integriert bzw. fragt eine Service-Registry an. Im Gegensatz zur clientseitigen Lösung wird weniger und vor allem einfacher Code benötigt. Dafür muss der Load-Balancer entsprechend ausfallsicher und skalierbar ausgelegt werden. Deswegen gibt es cloudbasierte Produkte, wie AWS Elastic Load Balancer (ELB) oder man verwendet auf jeden Service-Host eine Clusterlösung, wie Kubernetes oder Marathon als lokalen Proxy. Es gibt jedoch auch vorlagenbasierte Lösungen wie Consul, die eine dynamische Umkonfiguration von etablierten Load-Balancern, wie NGINX oder Apache HTTPD ermöglichen. Die anderen Muster beschäftigen sich damit, ob mehrere Services sich einen Host oder ein virtuelles Image teilen. Neben der besseren Ressourcennutzung spricht auch ein einfacheres Management für eine Mehrservice-Lösung.

Je nach Anforderung und Unabhängigkeit der Dienste wird es oft eine Mischung zwischen exklusivem Host-pro-Service und geteiltem Host geben. Je mehr sich jedoch leichtgewichtige Container durchsetzen, wird sich gerade bei Verwendungen heterogener Produkte und Programmiersprachen immer mehr Docker als Lösung für Microservices anbieten. Um einen gemeinsamen Datenbestand für alle Services und damit einen Engpass zu vermeiden, soll jeder Dienst seine eigenen Daten verwalten. Hier wird beim "Database-per-service"-Muster bewusst eine Redundanz von Daten in Kauf genommen. Ebenso kann jeder Dienst die für ihn geeignete Datenbanktechnologie und -produkt wählen. Wenn trotzdem eine einheitliche und konsistente Sicht auf einen Ausschnitt der Gesamtdaten benötigt wird, kann diese mit dem ereignisorientierten CQRS-Muster [9] erreicht werden. Hier kann wieder die z-Achse des Skalierungswürfels angewandt werden, was voraussetzt, dass die Daten entsprechend replizierbar und partitionierbar sind. Eine Voraussetzung für Microservices ist ja, dass die Dienste untereinander nur lose gekoppelt und zustandslos sind. Nur so können diese unabhängig voneinander entwickelt, deployt und skaliert werden.