Adaptable TeaStore Application

• Adaptable TeaStore is a microservice benchmark featuring operational adaptability through structural reconfiguration, modular service design, and multi-mode variability.
• The system employs MAPE-K feedback loops, formal configuration models, and energy-aware controls to optimize performance, resource scaling, and fault recovery.
• Advanced adaptation mechanisms integrate operator patterns, aspect-oriented programming, and rigorous formal analysis to ensure safe and seamless dynamic reconfigurations.

Adaptable TeaStore Application

Adaptable TeaStore refers to a family of reference implementations and extensible microservice architectures, collectively centered on the canonical TeaStore benchmark, whose primary design goal is operational adaptability. This encompasses structural and behavioral reconfiguration at runtime, modular service design, self-adaptive control loops, and coordinated multiservice adaptation in the face of performance, resilience, or energy consumption requirements. Multiple research efforts have advanced the model, architectural, and implementation strategies for Adaptable TeaStore, spanning formal configuration models, software product line concepts, self-adaptive MAPE-K loops, model-driven adaptation frameworks, resource- and energy-aware variants, and choreography- or aspect-based dynamic adaptation (Bliudze et al., 2024, Truyen, 29 Dec 2025, Gallone et al., 29 Dec 2025, Palma et al., 29 Dec 2025, Medeiros et al., 29 Dec 2025, Shahin et al., 2014, Sedighiani et al., 2021).

1. Architectural Model and Configuration Space

The core of the Adaptable TeaStore lies in a service classification and configuration space designed for maximal functional coverage and runtime reconfigurability. The architecture discriminates between mandatory and optional services, as well as flavour and mode variability (e.g., native, external, or local fallback; full- or low-power mode):

• Mandatory services: WebUI (entry point), Persistence (DB access), Image Provider (image serving). The minimal viable system always includes these.
• Optional services: Auth (stateless authentication), Recommender (ML or heuristic suggestions), Local Static DB/Images (fallback for Persistence/Image Provider), Third-party providers (external DB, image/CDN, SSO).
• Flavours: For both Persistence and Image Provider, exactly one of the core, external, or local static variant must be active per configuration.
• Modes: Services such as Recommender and Image Provider can be toggled between full and low-power operation, either fully or per-request.

Formally, the set of valid configurations $C$ is defined over the sets of services $S$, mandatory subset $M$, optional $O$, and third-party $T$, subject to constraints (unique provider per service, fallbacks for external failures, hierarchical fallback logic for user-based features if Auth is absent):

$$C = \{ (m, o) \mid m \subseteq \mathcal{P}(M),\; M \subseteq m,\; o \subseteq O \}$$

with flavour and mode constraints as specified above (Bliudze et al., 2024).

2. Adaptation Mechanisms and Control Patterns

Adaptability in TeaStore is enacted via a combination of monitoring, policy-driven control logic, and well-defined reconfiguration operations. The principal control patterns include:

• Runtime service (de)activation and mode switches: An Adaptation Manager ensures the presence of all mandatory services and switches to local or downgraded fallbacks as required (e.g., LocalDB if Persistence fails, low-power mode under load).
• Resource scaling: Load and performance hotspots trigger fine-grained resource scaling decisions (e.g., spawning or despawning WebUI/Recommender instances), with soft or hard service limits.
• Failure recovery: Automated detection via heartbeats and timeouts, followed by deterministic failover to local static variants and health-aware reversion to primary services.
• Configuration parameterization: Each service exposes tunable parameters (e.g., thread limits, cache size, algorithm selection) via centralized or distributed configuration stores, supporting hot-swapping of some parameters at runtime.

These mechanisms may be formalized as LaTeX-style procedures and predicates governing service state, resource usage, and mode selection (Bliudze et al., 2024).

3. Models and Languages for Systematic Adaptation

Several formal and practical frameworks underpin the engineering of the Adaptable TeaStore:

• Orthogonal Variability Model (OVM) and Metagraphs: OVMs define variation points (VP), variants (V), and constraints (requires/excludes, alternative-groups) for SaaS customizations. Metagraph-based validation ensures only permitted combinations of features for each tenant or context, with validation algorithms exhibiting linear runtime overhead (Shahin et al., 2014).
• Chips language: A component- and resource-aware language enabling specification of TeaStore’s functional blocks, mapping to physical or logical hosts, and embedding control-theoretic logic (notably, direct-discrete PID controllers for response-time regulation) (Gallone et al., 29 Dec 2025).
• AIOCJ (Choreographies): A peer-to-peer multiparty language supporting dynamic adaptation points with deadlock-free guarantees, enabling rules that react to environmental conditions, fallbacks, and coordinated rewiring of service dependencies on-the-fly (Palma et al., 29 Dec 2025).
• BASBA framework: A model-based approach to adaptation using UML-style metamodels, quality requirements, and ten reusable tactics (skip, add, replace activity; parallel/serial exec; re-execute; compressor, aggregate, reduce, cache). The pipeline generates monitoring, planning, and adaptation artifacts, cleanly separating adaptation logic from core services (Sedighiani et al., 2021).

All approaches aim to achieve modular adaptation plans, enforce constraints, and maintain system correctness under dynamic reconfiguration.

4. Self-Adaptive Feedback Loops and Energy Awareness

Self-adaptation in TeaStore is typically realized as a MAPE-K loop, instantiated at either system or service level:

• Feedback loop structure: The Monitor collects service- and resource-level metrics. The Analyzer checks for SLA or policy violations. The Planner selects adaptation plans according to a finite feature/model space. The Executor applies adaptations (switching algorithms, scaling, enabling/disabling services). Knowledge includes configuration history and feasible states (Medeiros et al., 29 Dec 2025, Truyen, 29 Dec 2025).
• Energy consumption as control objective: Integration of EnCoMSAS (sidecar container monitoring tool) enables real-time measurement of per-microservice energy (via Scaphandre or PowerAPI). Energy-based adaptation plans are possible, with empirical evidence demonstrating a strong correlation between CPU utilization and service-level power draw, while memory usage is largely decoupled.
• Policy-based switching: For instance, when Recommender exceeds a pre-set relative energy threshold, it is disabled or shifted to a low-power algorithm; reverted when below the threshold. Computation of energy uses the trapezoidal rule over sampled power values.

Energy-aware adaptation is context-sensitive: the most energy-efficient algorithm depends on hardware and deployment. Tooling overhead (from EnCoMSAS and related monitors) is non-negligible but modest compared to total ecosystem consumption (Medeiros et al., 29 Dec 2025).

5. Modularization, Planning, and Control Coordination

Robust self-adaptation in production architectures requires both fine-grained and system-wide control. Key strategies include:

• Operator pattern (Kubernetes): A cluster-level controller with CRDs (e.g., TeaStoreConfig) ensures transactional, converged adaptation across all service replicas. Operators handle multi-step planning (e.g., blue/green ML model deployment), system-wide policy enforcement, and idempotent reconciliation (Truyen, 29 Dec 2025).
• MAPE-K architectures: External engines (e.g., Rainbow-on-K8s) model complex adaptation strategies, balancing clusters and service composition invariants.
• Aspect- and context-oriented programming: When per-request or intra-service adaptation granularity is needed, AOP and COP mechanisms weave probes and effectors at method, class, or request-context scope. This enables adaptation contracts (e.g., /adapt/state APIs) for fine-grained external drive.
• Multi-tiered architecture: Combining operators (global convergence and planning), architecture-level controllers (MAPE-K engines), and fine-grained weaving (AOP, COP) maximizes adaptability and code modularity across microservice deployments (Truyen, 29 Dec 2025).

The tension between expressiveness (granular adaptation) and control (system-wide invariants) motivates hybrid and layered designs.

6. Formal Analysis, Correctness, and Guarantee Mechanisms

Adaptable TeaStore research places strong emphasis on correctness, analyzability, and resilience. Mechanisms include:

• Configuration validation: Metagraph-based algorithms for OVMs, ensuring all (syntactic/semantic) constraints are satisfied; scalable to large configuration spaces and multi-tenant scenarios (Shahin et al., 2014).
• Deadlock-freedom and communication safety: Choreographic approaches enforce global invariants and guarantee non-blocking progress, even under dynamic adaptation (Palma et al., 29 Dec 2025).
• Formal models for control: PID controllers are mathematically specified and analyzed for overshoot, settling time, and robustness properties. BIP or model-checking toolchains are employed for state-space exploration, invariant checking, and validation of Quality-of-Service under injected faults or environmental variability (Gallone et al., 29 Dec 2025).
• Testing and monitoring: Adaptation engines integrate with monitoring layers and maintain dashboards and metrics for triggers, plan deliveries, and system health.

These techniques ensure that Adaptable TeaStore configurations remain safe, performant, and predictable—even in the presence of dynamic reconfiguration and environmental uncertainty.

---

References:

• (Bliudze et al., 2024) Adaptable TeaStore
• (Truyen, 29 Dec 2025) Decoupling Adaptive Control in TeaStore
• (Gallone et al., 29 Dec 2025) Fancy Some Chips for Your TeaStore? Modeling the Control of an Adaptable Discrete System
• (Palma et al., 29 Dec 2025) Adaptable TeaStore: A Choreographic Approach
• (Medeiros et al., 29 Dec 2025) Adaptable Teastore with Energy Consumption Awareness: A Case Study
• (Shahin et al., 2014) An Aspect-Oriented Approach for SaaS Application Customization
• (Sedighiani et al., 2021) BASBA: a framework for Building Adaptable Service-Based Applications