Adaptable TeaStore Microservice Architecture

• Adaptable TeaStore is a benchmark for adaptable microservices, enabling runtime configuration changes via formal adaptation mechanisms.
• It integrates mandatory and optional services with multiple deployment flavors to maintain availability and optimize energy use.
• The system employs control-theoretic, choreographic, and decoupled self-adaptive strategies to balance performance, resilience, and energy efficiency.

Adaptable TeaStore is an advanced microservice reference architecture that extends the classic TeaStore application to model, benchmark, and analyze adaptable and self-adaptive systems. It was introduced to address the need for robustness and flexibility in distributed cloud environments, enabling runtime transitions among multiple configurations and supporting system-wide adaptation in response to operational, infrastructural, and energy-related events. Adaptable TeaStore serves as both a research case study and an implementation testbed for adaptation and self-adaptive control, featuring formal adaptation mechanisms, third-party integration, and energy-awareness extensions (Bliudze et al., 2024, Palma et al., 29 Dec 2025, Gallone et al., 29 Dec 2025, Truyen, 29 Dec 2025, Medeiros et al., 29 Dec 2025).

1. Architecture and Service Model

Adaptable TeaStore extends the original static TeaStore by distinguishing between mandatory and optional services, and by supporting multiple deployment flavors for core microservices. Its logical components are:

• WebUI (mandatory): Entry point and orchestrator for all user requests; coordinates all other services.
• Persistence (mandatory): Database: supports two flavors—remote (with local cache) and local static (fallback).
• Image Provider (mandatory): Supplies product images; supports remote provider (with local cache) and local static fallback.
• Auth (optional): Handles authentication and external SSO; can be toggled between available and unavailable.
• Recommender (optional): Offers product recommendations; supports "none," low-power (popularity-based), and full-power (stateful, ML-based) modes.

Service variants are formally captured as tuples:

$$(v_P, v_I, v_A, v_R) \in V_{\text{Persistence}} \times V_{\text{Image}} \times V_{\text{Auth}} \times V_{\text{Recomm}}$$

with e.g. $V_\text{Persistence}=$ {remote, static}, $V_\text{Recomm}=$ {none, low-power, full-power}.

Mandatory services (WebUI, Persistence, Image Provider) ensure minimal end-user functionality, while optional services (Auth, Recommender) provide enhanced features but can be dropped or degraded to maintain system liveness during failures or attacks. Multiple deployments of the same service (e.g., remote, local-cache, fallback static) allow the system to rapidly compensate for outages and shift between quality-of-service levels (Bliudze et al., 2024, Palma et al., 29 Dec 2025).

2. Configuration, Adaptation, and Third-Party Integration

Adaptable TeaStore supports dynamic configuration and flavor selection for each service. Deployment topologies include:

• Barebone: Only mandatory services, all in static local mode (read-only, minimal functionality).
• Barebone + Low-Power Recommender: Adds a popularity-based recommender, still with local static backends.
• Full (outsourced): Full suite of services, with external providers and local caches on standby; recommender in full-power mode.

External, outsourceable services (Persistence, Image Provider, Auth) must expose identical RESTful APIs to their local counterparts, ensuring drop-in replacement and seamless failover. Endpoint rebinding, credential injection, and failover policies are managed via configuration layers (e.g., Spring Cloud Config, K8s ConfigMaps). Integration with third-party SSO is accomplished via protocols such as OAuth2/OpenID Connect.

Dynamic adaptation is achieved through:

• Health and latency monitoring: Centralized monitoring agent aggregates response times and error rates.
• Policy-driven adaptation: Resource-management rules switch endpoints, enable/disable services, scale instances, or change recommendation algorithms.
• Failure, attack, and load adaptation: The system may degrade to local stand-ins, harden authentication, enable circuit breakers, or trigger resource scale-outs in response to observed events (Bliudze et al., 2024).

3. Adaptation Mechanisms: Models, Algorithms, and Control Loops

Adaptable TeaStore implementations utilize a spectrum of adaptation control strategies:

• Choreographic Adaptation (AIOCJ): Using the AIOCJ language, adaptable behaviors are specified via scopes—regions of code annotated with adaptation tags—and rules that are atomically swapped at runtime. Adaptations include service switchover (remote/local), authentication enable/disable, and recommender mode transitions. Adaptation logic can inspect environment variables, controller flags, and service states. AIOCJ guarantees communication safety and deadlock-freedom by construction, and every adaptation is deployed and validated using a formal protocol (Palma et al., 29 Dec 2025).
• Control-Theoretic Modelling (Chips + BIP): The Chips language enables structural decomposition of TeaStore into functional components and formalizes adaptation as a discrete-time control problem, for instance, resizing cache allocation using a PI control law to maintain response times at a setpoint:

$$\begin{aligned} e_k &= R_{\text{desired}} - \tau_k \ z_{k+1} &= z_k + e_k \ u_k &= K_p e_k + K_i z_k \ c_{k+1} &= c_k + u_k + w_k \end{aligned}$$

Here, $c_k$ is cache size, $\tau_k$ is response time, and $w_k$ is disturbance. This approach ensures stability (via eigenvalues), and the adaptation logic is implemented as composable, testable Chips components (Gallone et al., 29 Dec 2025).

• Decoupled Self-Adaptive Control: Adaptation logic is separated from application logic, employing MAPE-K controllers, the Kubernetes Operator pattern, or legacy programming techniques such as Aspect-Oriented Programming (AOP) and Context-Oriented Programming (COP). Operators reconcile system state with desired configuration via CRDs, ensuring system-wide consistency. Architecture-based controllers express domain strategies (e.g., “scale then switch to low power”), while AOP/COP target fine-grained, per-request adaptations. A three-tier architecture combines these layers for macro (global), meso (service-group), and micro (per-instance) control (Truyen, 29 Dec 2025).

4. Energy Awareness: Instrumentation and Results

The Adaptable TeaStore has been used as an empirical testbed for integration with energy consumption monitoring platforms, notably EnCoMSAS (Medeiros et al., 29 Dec 2025).

• Monitoring Architecture:
  • Monitoring agents (e.g., Scaphandre with Intel RAPL) gather power data exposed as Prometheus metrics.
  • A Data Aggregator (MonitorScheduler/EnergyConsumptionCollector) queries power data, maps process IDs, and integrates energy using:

  $$E \approx \sum_{i=0}^{n-1} \frac{P_i + P_{i+1}}{2} \Delta t$$ - The Adaptation Manager (AdaptationScheduler + ConditionEvaluator) reads real-time energy data, applying adaptation logic to change operational modes.

• Empirical Results:

  • Strong empirical correlation between CPU usage and energy consumption (e.g., Pearson $p=4.5\times10^{-10}$ to $5.9\times10^{-6}$ depending on scenario and algorithm).
  • Low-power recommender mode can halve CPU consumption relative to full mode.
  • The impact of EnCoMSAS instrumentation on total energy usage is modest (e.g., ≈215 J per 100 s run, $RSEC=1.47\%$ for Adaptable TeaStore recommender; WebUI ≈1 100 J).
  • Adaptation rules (e.g., switch to low-power if energy exceeds 1.5 × historical baseline) can be embedded directly and validated across heterogeneous hardware (Grid5000 testbed).
  • Memory usage displays no significant correlation with energy, highlighting the dominance of CPU-load-driven effects.

Significance: These results demonstrate the feasibility of integrating real-time, fine-grained energy metrics into adaptation controllers, and empirically confirm the validity of energy-performance trade-offs and adaptation efficacy in realistic microservice deployments (Medeiros et al., 29 Dec 2025).

5. Case Studies, Scenarios, and Benchmarking

Adaptable TeaStore has been exercised under diverse operational scenarios to benchmark and illustrate adaptation logic:

Scenario	Event/Trigger	Adaptation Action(s)	Typical Outcome
Database failure	DB timeouts	Switch Persistence/Image to local static; display notice	Maintains minimal availability
Cyberattack	All external services down	Disable Auth, switch to statics	Continues browsing
Cloud outage	Regional external failure	Move to barebone config, redeploy in other region	Preserves liveness
Traffic spike (benign)	Recommender resource saturation	Switch Recommender to low-power mode	Recover response time
DDoS	Massive untrusted load	Enable circuit breakers, degrade services, force cache	Limits cascading overload

Performance and energy profiling under these scenarios shows that local static services yield sub-20 ms page loads, compared to 150 ms with remote calls, and energy consumption increases up to 80% when running recommender in full-power or under non-adaptive policies (scenario- and cluster-dependent) (Bliudze et al., 2024, Medeiros et al., 29 Dec 2025).

6. Design Trade-Offs, Limitations, and Future Directions

Adaptable TeaStore exposes fundamental trade-offs in the design of adaptable microservice systems:

• Performance vs. Resilience: Outsourcing core services enhances peak throughput but introduces single points of failure; local stand-ins reduce feature set but guarantee availability.
• Modularity vs. Complexity: Fine-grained microservices maximize adaptation flexibility, at the cost of deployment and communication overhead.
• Adaptation Mechanism Expressiveness: Choreographic approaches (AIOCJ) provide rigorous correctness, but currently lack constructs for non-functional policies (autoscaling, geo-deployment). Operator- and architecture-based approaches cover a broader range of non-functional adaptations.
• Error Resilience: Current limitations include the inability to gracefully model and recover from certain external failures, particularly in choreographies without explicit resilience constructs.
• Energy-Aware Control: Embedded adaptation policies are presently simple threshold rules; future work includes adoption of multi-objective MAPE-K loops balancing energy, performance, and utility.

Open questions include the composability of adaptation rules, minimization of intrusive service-state variables, and comparative benefits of choreography vs. orchestration for cloud-native adaptability (Palma et al., 29 Dec 2025, Medeiros et al., 29 Dec 2025).

7. Research Impact

Adaptable TeaStore provides a rigorously-defined, open, and extensible reference point for research on adaptive and self-adaptive systems, enabling unified experimentation with architectural, algorithmic, and quantitative techniques. Its integration of formal adaptation mechanisms, third-party service modeling, and energy-awareness tools has facilitated empirical, control-theoretic, and statistical studies across cloud-native and energy-constrained contexts (Bliudze et al., 2024, Palma et al., 29 Dec 2025, Medeiros et al., 29 Dec 2025, Truyen, 29 Dec 2025, Gallone et al., 29 Dec 2025). The system continues to serve as a benchmark for innovations in both foundational and applied aspects of dynamic adaptation in microservices.