---
title: 'Adaptable TeaStore: Self-Adaptive Cloud Microservices'
url: https://www.emergentmind.com/topics/adaptable-teastore-specification
type: topic
---

# Adaptable TeaStore: Self-Adaptive Cloud Microservices

The Adaptable TeaStore Specification describes a microservice-based, adaptable reference architecture designed to investigate, benchmark, and verify approaches to runtime adaptation in distributed cloud systems. It extends the original TeaStore reference application with formally specified architectures, adaptation points, configuration languages, dynamic adaptation rules, and correctness criteria suitable for research on resilient and self-adaptive microservice deployments [2512.23497] [2412.16060] [2512.23495] [2512.23499] [2512.23496].

## 1. Architectural Model and Components

Adaptable TeaStore generalizes the baseline TeaStore architecture to encompass a spectrum of configurations and runtime transitions among them. The core components (each as a microservice) are:

- **WebUI** (role W): Orchestrator and façade managing user-facing workflows and coordination.
- **Persistence** (role P): Database access layer, which may be local, remote, or a cache-proxy.
- **Image Provider** (role I): Source for product images, offering multiple deployment flavors (local, external, cached).
- **Auth** (role A): Optional authentication and session management service (can be in available/unavailable state).
- **Recommender** (role R): Optional service delivering product recommendations in various modes ("disabled", "low-power" [popularity-based], "full-power" [ML-based]).

Configurations distinguish **mandatory services** (WebUI, Image Provider, Persistence) from **optional ones** (Auth, Recommender). The system supports third-party and external SaaS integration for all but WebUI, with failover to local fallbacks [2412.16060].

At runtime, the system may transition along axes such as enabling/disabling Auth, selecting a recommender flavor, and switching between local/remote Persistence or Image services. Clients interact with WebUI, which coordinates all other components via parallel and sequential orchestrations [2512.23497].

## 2. Formal Specification and Configuration Language

Adaptable TeaStore provides a formal configuration schema and DSL for system declaration. The configuration grammar (EBNF fragment):

```
System → “system” Identifier “{” ServiceDecl+ “}”
ServiceDecl → ServiceType Identifier [ “:” Flavor ] “{” PropertyList “}”
ServiceType → “WebUI” | “Persistence” | “ImageProvider” | “Auth” | “Recommender”
Flavor → “full” | “lightweight” | “low-power” | “disabled”
PropertyList → (Property (“;” Property)*)?
Property → Identifier “=” (string | number | “true” | “false”)
```

Example (YAML-like):

```yaml
system TeaStoreVariant {
  WebUI ui { port=8080; replicas=2 }
  Persistence db : cloud { provider="supabase"; region="eu-west-1" }
  ImageProvider imgProv : full { cacheSizeMB=512 }
  Auth authSvc : full { externalSSO=true; oauthProviders=["google","facebook"] }
  Recommender rec : low-power { algorithm="popularity"; syncIntervalSec=60 }
}
```
[2412.16060]

This schema supports the declaration of mandatory and optional services, deployment flavors (local, outsourced, disabled), and relevant operational properties, allowing for clear separation between business logic and adaptation logic [2412.16060][2512.23495].

## 3. Adaptation Mechanisms and Choreographic Coordination

Adaptation is expressed using *adaptation points* (scopes) and *rules*, particularly when formalized via the AIOCJ choreographic language. Scopes annotate points in the global choreography where adaptation is permitted, each with associated properties:

```aiocj
scope @W { ... } prop { N.tag = "page-compiler" };
```

Rules match on these properties and environmental context, describing choreography fragments that can dynamically replace the scoped code:

```aiocj
rule {
  on { N.tag=="recommender" and E.recommender=="low-power" }
  do {
    // Interactions for popularity-based recommendations
  }
}
```
[2512.23497]

The AIOCJ runtime selects and enacts adaptation rules atomically and distributes them to involved roles, ensuring communication safety and deadlock freedom at every stage. Adaptation conditions can reference scope, environment, and local variables. This design enforces correctness-by-construction within dynamic system evolution.

Alternative adaptation approaches include the Operator pattern (declarative control via Kubernetes CRDs), event-driven rule engines (as in AdaptiFlow), and local behavioral variation through AOP/COP techniques. These decouple adaptation planning and coordination from internal service logic, supporting modular and system-wide adaptation [2512.23499][2512.23495].

## 4. Supported Adaptation Scenarios and Transition Dynamics

The specification formalizes several canonical adaptation scenarios, realized by rule sets and corresponding choreographies:

- **Low-power recommender**: Activated by an environment variable, replaces the recommender scope with interactions for a popularity-based algorithm.
- **Full-power recommender**: Triggers richer recommendation workflows and adds authentication steps if required.
- **Authentication**: Conditionally enables user authentication and token issuance.
- **Authenticated page info**: Routes requests to authenticated endpoints based on token presence.
- **Combined Auth + Full recommender**: Applies all relevant rules, with each adaptation point coordinated independently and transformations composed orthogonally.

Transitions are orchestrated so that, at each adaptation point, the system atomically and consistently switches to the appropriate variant, either by choreography rewriting or rule-driven action [2512.23497].

Operational resilience mechanisms include circuit breakers, automated failover, state synchronization, and graceful degradation, specified via adaptation rules and supported by cost/QoS optimization formulas:

$$
C_{total} = \sum_{s \in Services} (c_s^{compute} \cdot n_s + c_s^{transfer} \cdot t_s)
$$
subject to:
$$
\forall s: \mathit{ResponseTime}_s \leq \mathit{QoS}_s
$$
[2412.16060]

## 5. Correctness, Invariants, and Formal Guarantees

Adaptable TeaStore specifications emphasize *correctness-by-construction*. Notably:

- **Communication Safety**: All message exchanges are statically matched and consistent under choreography projection.
- **Deadlock Freedom**: There are no reachable deadlock states in well-typed choreographies, before, during, or after adaptations.
- **Atomicity of Adaptation**: Code swaps occur atomically for all participants, preventing partial updates or protocol mismatches.

Formally, using global types:

**Theorem (Subject Reduction):**
If $\Gamma \vdash C$ and $C \rightarrow C'$, then $\Gamma \vdash C'$.

**Theorem (Deadlock Freedom):**
If $\Gamma \vdash C$, then $C$ is deadlock-free.

System-level invariants required for validity in any deployment (excerpt):

- $I_1:$ Deployed(WebUI)
- $I_2:$ Deployed(Persistence\_localStatic) $\lor$ Deployed(Persistence\_cloud)
- $I_3:$ Deployed(ImageProvider\_localStatic) $\lor$ Deployed(ImageProvider\_full|lightweight)
- $I_4:$ Deployed(Auth\_full) $\lor$ Deployed(Auth\_disabled)
- $I_5:$ Recommender.mode $\in \{\text{full}, \text{low-power}, \text{disabled}\}$

Verification uses propositional logic, cost-vs-QoS constraints, and model-checking approaches, depending on the implementation paradigm [2512.23497][2412.16060][2512.23495][2512.23496].

## 6. Implementation Strategies and Multi-Tiered Adaptation

Adaptable TeaStore supports a diversity of adaptation integration strategies:

- **Choreographic Adaptation (AIOCJ)**: Encodes global workflows, adaptation points, and transformation rules at the language level, guaranteeing strong runtime safety.
- **Declarative Operator Control**: Uses Kubernetes CRDs, controllers, and reconciliation loops to centrally aggregate metrics and schedule global adaptations (e.g., enabling low-power mode cluster-wide).
- **Decentralized, Event-Driven Rule Engines**: As exemplified by AdaptiFlow, supports local monitoring, rule-based adaptation, and system-wide coordination via event broadcast and subscription [2512.23499].
- **Fine-Grained In-Process Modularity**: Aspect-Oriented Programming and Context-Oriented Programming layer adaptation logic externally to the service codebase, providing maximal code modularity but potentially weaker global consistency [2512.23495].

These approaches are complementary; multi-tiered deployment combines global control, architectural reasoning, and localized behavioral adaptation. Trade-offs must be managed between system-wide consistency, advanced planning (e.g., event aggregation, dark launch), and code-level modularity:

| Approach            | Consistency | Planning | Modularity |
|---------------------|-------------|----------|------------|
| Operator pattern    |    1.0      | 0.8      |   0.3      |
| AOP / COP           |    0.0      | 0.5      |   1.0      |
| Architecture-based  |   0.7       | 1.0      |   0.5      |

[2512.23495]

## 7. Control-Theoretic Modeling and Verification

Configuration and adaptation in the Adaptable TeaStore can also be expressed in control-theoretic terms, as detailed using the Chips modeling language. Control loops adjust system parameters (e.g., cache size) to regulate measurable metrics (such as response time), employing designs like discrete PID controllers with bounded actuation and performance constraints:

$$
u[k] = K_p\,e[k] + K_i\sum_{j=0}^k e[j]\Delta t + K_d\,\frac{e[k]-e[k-1]}{\Delta t}
$$

where $e[k] = T_r - T_a[k]$ is the error signal between required and actual response times, $u[k]$ is the control action, and tuning parameters ensure stability and constraint satisfaction. Models are verifiable for deadlock-freedom, property preservation, and stability within BIP or similar frameworks [2512.23496].

---

The Adaptable TeaStore specification provides a rigorously defined, formalized, and extensible framework for modeling, benchmarking, and verifying self-adaptive, microservice-oriented cloud systems. Its specification supports declarative configuration, multiple adaptation paradigms, system- and component-level guarantees, and an array of adaptation strategies, making it an authoritative foundation for experimental and applied research in distributed adaptable architectures.

Source: https://www.emergentmind.com/topics/adaptable-teastore-specification