Ressourcen pro Klient

Hier wird für jede Klientanwendung ein eigener Cluster der Anwendung bereitgestellt. Fällt einer der Cluster aus, so entfällt zwar die Funktionalität der abhängigen Klientanwendung, andere Klientanwendungen funktionieren jedoch weiterhin.

Ressourcen pro Anwendung

Bei dieser Variante wird ein Softwaresystem nach dem Verwendungszweck aufgeteilt und jedem dieser Teilsysteme eine bestimmte Menge an Ressourcen (Rechenzeit, Speicher, Bandbreite etc.) durch ein Container-Verwaltungssystem zur Verfügung gestellt.

Beispielsweise kann ein Zahlungssystem in ein Kreditkarten-Abbuchungssystem und ein Kontoüberweisungssystem aufgeteilt und in getrennten Containern gehostet werden. Fällt eines der Teilsysteme aufgrund einer Überlastung aus, so können Zahlungen weiterhin mit dem jeweils anderen Teilsystem durchgeführt werden.

Ressourcen pro Operation

Hier wird die Schnittstelle einer Anwendung feingranular nach Operationen geteilt und jeder Operation eine bestimmte Menge an Ressourcen bereitgestellt. Diese Variante eignet sich besonders für Fassaden und Portale, welche mehrere Systeme im Hintergrund ansprechen.

Steht beispielsweise die Methode payByCreditCard() einer API, etwa aufgrund einer Überlastung oder des Ausfalls des dahinter liegenden Kreditkartensystems, nicht zur Verfügung, kann dennoch die Operation payByWireTransfer() aufgerufen werden.

Um eine derart feingranulare Aufteilung innerhalb einer Anwendung zu ermöglichen, werden eigene Frameworks wie Hystrix eingesetzt.

Ressourcen pro Endpunkt

Hier wird für jede Verbindung zu einer externen Ressource ein eigener Verbindungs-Pool oder Thread-Pool zur Verfügung gestellt.

Hierbei muss jedoch beachtet werden, dass beim Ausfall einer Ressource nicht immer ein Fallback erfolgen sollte. Fällt etwa ein Caching-System aus, so würde ein Fallback auf die Datenbank zu einer Überlastung derselben führen und somit einen Kaskadenfehler erzeugen.