Adaptable TeaStore Benchmark

• Adaptable TeaStore Benchmark is a configurable microservice e-commerce framework designed to evaluate self-adaptation, operational resilience, and energy efficiency in cloud-native environments.
• It distinguishes between mandatory, optional, and third-party services, enabling fine-grained testing of architectural choices and adaptation mechanisms using control-theoretic and event-driven methods.
• The framework provides comprehensive metrics—such as adaptation latency, consistency scores, and energy consumption—to support rigorous benchmarking and comparative analysis of adaptive systems.

The Adaptable TeaStore Benchmark is a configurable microservice e-commerce reference application and experimental framework designed to evaluate self-adaptation, operational resilience, and energy-awareness in modern cloud-native systems. Building on the original TeaStore, it provides an explicit distinction between mandatory, optional, and third-party services and supports a wide spectrum of adaptation mechanisms across software architecture, control-theoretic, energy-aware, and event-driven models. Adaptable TeaStore serves as a central case study in numerous architectural, autonomic, and control frameworks, offering both a practical implementation platform and a set of benchmarking scenarios for rigorous evaluation and comparative analysis of self-adaptive software systems (Bliudze et al., 2024, Truyen, 29 Dec 2025, Ndadji et al., 29 Dec 2025, Medeiros et al., 29 Dec 2025, Gallone et al., 29 Dec 2025).

1. Architectural Decomposition and Adaptation Space

Adaptable TeaStore implements a microservice architecture partitioned into three main categories:

• Mandatory services: WebUI (front-end), Image Provider (image hosting/resizing), Persistence (stateful product and order data).
• Optional services: Authentication (Auth), Recommender.
• Third-party/external services: External Image-as-a-Service, Database-as-a-Service (DaaS), SSO/Auth providers (e.g., OAuth, SAML/SSO).
• Local fallback services: Local static image and DB services for failure scenarios.

Each provider service can be realized either as an internal container/VM or as an external SaaS/PaaS dependency, with automatic local fallback in case of failure. The architecture exposes adaptation points at the level of individual service deployment (choice of implementation), operational "flavor" (e.g., low-power vs. full recommender), and integration endpoints (Bliudze et al., 2024). Configuration parameters include per-service scaling, placement/topology, adaptation triggers and thresholds, and handling of workload spikes or dependency failures. The design enables fine-grained testing of system behavior under varied operational and failure scenarios.

2. Self-Adaptation Processes and Key Properties

Adaptable TeaStore benchmarks are focused on three key properties of self-adaptive systems (Truyen, 29 Dec 2025):

• System-wide consistency: Adaptation actions (e.g., switching to low-power mode) must converge all replicas of a microservice to the same state.
• Planning: Adaptations may require stepwise planning (e.g., "dark launches," model warm-up, staged rollouts) before activation and must accommodate fallbacks if necessary conditions are not satisfied.
• Modularity: Adaptation logic, such as probes, rules, and effectors, must be decoupled from business logic to maximize reusability and minimize code intrusion.

Minimal Monitoring (M) and Effector (E) interfaces expose REST endpoints for metric collection and configuration changes; Analysis (A), Planning (P), and Knowledge (K) phases are left for implementation by the experimenter. The adaptation space is evaluated over scenarios ranging from database outages and service downtimes to cyberattacks, workload surges, and DevOps-triggered reconfiguration (Bliudze et al., 2024, Truyen, 29 Dec 2025, Ndadji et al., 29 Dec 2025).

3. Control and Adaptation Implementation Paradigms

Three orthogonal implementation paradigms are used to realize self-adaptive control:

• Architecture-based (e.g., Rainbow on Kubernetes): External controllers maintain an architectural model over Kubernetes resources, declaring invariants for adaptation over components and connectors. This supports explicit planning and system-wide coordination but requires substantial architectural tooling (Truyen, 29 Dec 2025).
• Cloud-native Operator pattern: Custom Resources and reconciliation loops drive state changes and system-wide adaptations (e.g., scaling, config toggles) at the cluster level. Operators provide strong consistency but are more coarse-grained and can conflate infrastructure and business logic if not carefully modularized (Truyen, 29 Dec 2025).
• Legacy language techniques (AOP, COP): Aspect-Oriented and Context-Oriented Programming are used to insert fine-grained probes and behavioral variants into service code. This allows method-level or per-request adaptation (e.g., client-specific modes) without altering the core application, but has limited intrinsic support for coordination across replicas (Truyen, 29 Dec 2025).

These can be composed into a multi-tiered adaptation architecture:

Tier	Role & Mechanism	Adaptation Granularity
Tier 1	Global control (Operator or architectural controllers)	Replica/deployment (coarse)
Tier 2	Service-level (embedded or sidecar architectural models)	Service (meso)
Tier 3	Intra-service (AOP/COP, per-request layers)	Request/object (fine)

Inter-tier communication uses standardized REST endpoints, events, and configuration states, enabling integration and coordinated adaptation (Truyen, 29 Dec 2025).

4. Metrics, Scenarios, and Benchmarking Methodology

Adaptable TeaStore supports benchmarking along multiple quantitative dimensions:

• Adaptation time and latency: Time from trigger to system convergence (Δ).
• Consistency score: Fraction of replicas in the target state at a given time ($C(t) = \text{\# in mode} / \text{total \#}$).
• Planning horizon ($H$): Sum of preparatory steps' durations.
• Service latency, error rate, throughput, and resource utilization: Collected via standardized metrics collectors (Ndadji et al., 29 Dec 2025).
• Energy consumption ($E = \int_{t_0}^{t_1} P(t)dt$): Computed via continuous or trapezoidal-rule integration of power samples using tools like EnCoMSAS, with collection intervals and container-level granularity (Medeiros et al., 29 Dec 2025).

Workload scenarios are programmable, supporting regular, adversarial, and failure-induced conditions (e.g., DDoS simulation, benign surges, provider outages). Adaptation contracts are standardized through RESTful state and mode endpoints, with event semantics specified for precise trigger conditions.

An example table skeleton for scenario results: | Scenario | Adapt.Time (ms) | Lat.95% Before (ms) | Lat.95% After (ms) | Δ Resource Cost (%) | |----------------------------|----------------|---------------------|--------------------|---------------------| | Database Unavailable | 1,200 | 450 | 320 | +5 | | Cyberattack (Outage) | 1,800 | 500 | 340 | +8 | (Bliudze et al., 2024).

Statistical analysis utilizes Wilcoxon/Mann-Whitney, Shapiro (normality), and Pearson correlation tests for metric relationships. Benchmarking is typically performed over ≥30 runs for repeatability and significance (Medeiros et al., 29 Dec 2025).

5. Energy Consumption and Resource Analysis

Adaptable TeaStore benchmark supports detailed, tool-assisted energy consumption measurement and adaptation (Medeiros et al., 29 Dec 2025). EnCoMSAS (Energy Consumption Monitoring for Self-Adaptive Systems) integrates with TeaStore to provide:

• Per-microservice energy metering (e.g., for the Recommender variants).
• Energy-based adaptation logic, allowing mode-switches when energy or CPU metrics cross dynamic thresholds.
• Empirical results: Show that energy consumption is correlated closely with CPU usage, with negligible impact from memory usage; algorithmic efficiency interacts with hardware configuration, leading to cluster- and context-dependent energy-minimization choices.

Overheads of energy monitoring are measured and reported, with explicit inclusion of monitoring tool cost (e.g., Scaphandre + MongoDB per-run Joule overhead), ensuring accurate analysis of adaptive system efficiency (Medeiros et al., 29 Dec 2025).

6. Formal Modeling and Control-Theoretic Extensions

Control-theoretic techniques are exercised via the Chips language, which models TeaStore as a collection of functional blocks and embeds runtime feedback via discrete PID controllers (Gallone et al., 29 Dec 2025). In Chips:

• Component-based modeling: System, logical, and physical components are coupled via explicit synchronous signal flows.
• PID adaptation: Example: controlling cache size in the Image Provider to maintain target response times under dynamic loads.
• Formal specification: Controllers are designed and verified via state machines and plant equations, supporting stability and convergence analysis.
• Empirical conclusions: PID feedback suffices to bound latency, demonstrating benchmark suitability for hybrid discrete-continuous adaptive control experimentation.

7. Recommendations and Research Directions

Extensions and recommendations for rigorous benchmarking include:

• Standardized adaptation interfaces: Define RESTful endpoints for reporting and triggering mode changes; use JSON schemas for state exposure.
• Event and context specification: Precisely characterize triggers (e.g., “DatabaseUnavailableEvent”) and context propagation (e.g., custom HTTP headers with key-value adaptation context).
• Reference multi-tier adaptation implementations: Combine global (Operator/architecture), service-level (sidecars or embedded controllers), and local (AOP/COP) mechanisms in demonstrator stacks.
• Energy- and QoS-aware adaptation policies: Employ unified metrics and integrate with proactive or AI-driven planners to support complex, cross-service adaptation targets.
• Empirical rigor: Specify platform hardware, workload profiles, monitoring overheads, and use non-parametric statistics for validation (Medeiros et al., 29 Dec 2025, Truyen, 29 Dec 2025).

The Adaptable TeaStore benchmark thus serves as a foundational platform for methodologically sound research and comparative studies in adaptive microservice systems, supporting evaluation of consistency, planning, modularity, resource efficiency, and energy-awareness under realistic operational challenges.