Adaptable TeaStore: Self-Adaptive Cloud Microservices

• Adaptable TeaStore is a microservice-based reference architecture that enables runtime adaptation in distributed cloud systems.
• It features a formal configuration language, clearly defined adaptation points, and dynamic rules ensuring communication safety and deadlock freedom.
• The specification supports multiple adaptation strategies—from choreographic adaptation to control-theoretic modeling—facilitating rigorous research and practical benchmarking.

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 (Palma et al., 29 Dec 2025, Bliudze et al., 2024, Truyen, 29 Dec 2025, Ndadji et al., 29 Dec 2025, Gallone et al., 29 Dec 2025).

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 (Bliudze et al., 2024).

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 (Palma et al., 29 Dec 2025).

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):

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 } }

(Bliudze et al., 2024)

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 (Bliudze et al., 2024, Truyen, 29 Dec 2025).

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:

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:

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

(Palma et al., 29 Dec 2025)

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 (Ndadji et al., 29 Dec 2025, Truyen, 29 Dec 2025).

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 (Palma et al., 29 Dec 2025).

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$$

(Bliudze et al., 2024)

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 (Palma et al., 29 Dec 2025, Bliudze et al., 2024, Truyen, 29 Dec 2025, Gallone et al., 29 Dec 2025).

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 (Ndadji et al., 29 Dec 2025).
• 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 (Truyen, 29 Dec 2025).

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

(Truyen, 29 Dec 2025)

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 (Gallone et al., 29 Dec 2025).

---

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.