Adaptable TeaStore Microservice Benchmark

• TeaStore Microservice Application is a benchmark architecture in cloud-native research that separates mandatory and optional services for modular and resilient deployments.
• It integrates advanced adaptation techniques such as MAPE-K control loops, Bayesian optimization, circuit breakers, and API gateways to optimize performance.
• The design ensures dynamic reconfiguration and choreographic correctness, enabling graceful degradation and robust operational resilience in distributed systems.

The TeaStore microservice application is a canonical benchmark and reference architecture in cloud-native research, serving as a testbed for modelling techniques, resource management strategies, and advanced adaptation methodologies in distributed systems. Recent developments focus on a variant termed the "Adaptable TeaStore," which extends the original configuration to support modularity, resilience, and dynamic composition of mandatory and optional services. This architecture facilitates benchmarking, adaptive control, resource optimization, and correctness by construction in multiparty distributed applications (Bliudze et al., 2024, Truyen et al., 29 Dec 2025, Truyen, 29 Dec 2025, Palma et al., 29 Dec 2025).

1. Modular Architectural Design

Adaptable TeaStore is structured around a clear separation between mandatory (core) and optional (extendable or outsourceable) microservices. The mandatory components are indispensable for minimal functional scenarios, such as read-only usage, whereas optional services augment the feature set or enable outsourced integration.

Component Taxonomy

Category	Service Name	Role/Functionality
Mandatory	WebUI	JSP-based frontend; central API gateway
Mandatory	Persistence	RDBMS-backed DA layer; multi-instance cache
Mandatory	Image Provider	Image resizing; LFU cache
Optional	Auth	User login (BCrypt); stateless sessions
Optional	Recommender	Slope One/nearest-neighbor/fallback algorithms

Interaction flows mandate communication through REST endpoints, with the WebUI orchestrating inter-service calls. Startup phases trigger bulk data pulls from Persistence by Image Provider and Recommender. Optional components can operate in full, low-power, or disabled modes, and are resilient to downtime, e.g., anonymous fallback for Auth disruptions (Bliudze et al., 2024).

Outsourced scenarios introduce cache-fronting variants of Persistence and Image Provider, supporting failover and circuit-breaker logic for external dependencies.

2. Integration and Adaptation Patterns

Adaptable TeaStore leverages several architectural and deployment strategies for both classical and cloud-native microservices:

• API Gateway: WebUI acts as a front door, aggregating downstream service calls, remaining agnostic to whether backends are local or remote.
• Service Flavors: Dual-mode deployment (static vs. full-featured) is supported in Persistence and Image Provider.
• Health Checking & Service Discovery: Light registries (e.g., Eureka, Consul) drive heartbeat-based liveness, informing adaptation.
• Circuit Breakers & Bulkheads: Service failures (timeouts, error rates exceeding thresholds) automatically trigger configuration reversion, swapping degraded services for static local variants.
• Messaging/Event Notification: Adaptation events and data-import sequences propagate configuration changes.

The adaptation reactor pseudo-code illustrates the system’s periodic health polling and atomic configuration updates to maintain service continuity in face of component failures:

loop every Δ seconds: for each mandatory service S: if health(S) == DOWN: if S ∈ {Persistence, ImageProvider}: switchFlavor(S, localStatic) elif S == Auth: degradeMode(WebUI, anonymous) for Recommender: if throughput(Recommender) < θ_low: setMode(Recommender, fallback) elseif cpuUtil(Recommender) > θ_high: scaleOut(Recommender) if all external services healthy: revertAllToFullConfiguration()

(Bliudze et al., 2024)

3. Configuration and Resource Optimization

The offline performance optimization problem for TeaStore is formulated as finding the resource allocation vector $x$ (for CPU and memory across 7 service containers) that minimizes a utility function $u(x)$. Service Level Objectives (SLOs) require 99th-percentile tail latency $\leq 1000$ms and throughput $\geq 0.5$ req/s per tenant. The normalized cost $C(x)$ for allocations yields:

$$u(x) = \begin{cases} 1 + \frac{SLI_1(x) - 1000}{1000}, & \text{if } SLI_1(x) > 1000 \ C(x), & \text{otherwise} \end{cases}$$

Morris One-At-a-Time (MOAT) factor screening condenses the configuration space from $6^{14}$ to 2,048 points by analyzing the average influence ($\mu_i^*$) of each parameter on tail latency. This enables feasible sampling for algorithmic optimization (Truyen et al., 29 Dec 2025).

Parameter	μᵢ*	New min	New max
webuiCpu	0.62	750 m	1125 m
authCpu	0.45	625 m	1125 m
webuiMemory	0.40	768 Mi	1152 Mi
authMemory	0.27	640 Mi	1152 Mi
dbMemory	0.18	512 Mi	1152 Mi

Bayesian Optimization (BO-EI) consistently outperforms alternatives—BestConfig, random search—achieving near-optimal solutions with a sample budget ($T=100$ yields $\approx 82\%$ success, $0.012$ median $\Delta u$, and 28% median cost saving versus defaults). Factor screening is essential for exhaustive or comparative evaluations; standalone BO-EI is recommended for near-optimal tuning under limited sampling budgets.

4. Adaptive Control and Self-Adaptation

TeaStore’s self-adaptive behavior is modeled using the MAPE-K control loop (Monitor-Analyze-Plan-Execute-Knowledge), embedding adaptation logic as a feedback controller with explicit state variables $x(t)$ and effectors $u(t)$. System dynamics are approximated as:

$x(t+1) = A x(t) + B u(t) + d(t)$

$u(t) = K (r(t) - x(t))$

Model Predictive Control (MPC) plans actions over $N$-step horizons to minimize a quadratic cost $J$. Termination occurs when all metrics are within tolerance, adaptation invariants hold, or time limits are reached.

Multiple implementation strategies for decoupling adaptation logic include:

• Architecture-Based MAPE-K Engines: External controllers subscribe to metrics and drive adaptation via domain models.
• Kubernetes Operator Pattern: Custom Resource Definitions (CRD) manage macro-adaptations and system-wide consistency; level-based reconciliation is leveraged.
• Legacy Programming Techniques: Aspect-Oriented Programming (AOP) and Context-Oriented Programming (COP) inject fine-grained adaptation into business code via advice and dynamic layers.

Trade-offs involve granularity (local method vs. per-deployment), adaptation latency (ms-scale for AOP/COP vs. seconds-scale for Operator), and modularity. A multi-tier stack integrating Operators, architectural MAPE-K, and intra-service weaving is proposed for robust adaptation (Truyen, 29 Dec 2025).

5. Choreographic Correctness and Dynamic Reconfiguration

A choreographic realization using AIOCJ captures TeaStore’s multi-party communication as a global program, enabling by-construction correctness—deadlock freedom, communication safety—across adaptation and configuration transitions. Choreographies define adaptable scopes and rule-driven code replacements at runtime. For example, the barebone version involves:

• User requests (U) → WebUI orchestrator (W)
• Parallel fetches to Persistence (P) for textual info and Image Provider (I) for images
• Page compilation and response delivery

Adaptation rules, indexed by scope tags and environment variables, exchange choreographic fragments. This ensures all parties engage in globally consistent sequences and dynamically inject optional new features (e.g., low-power recommender).

Projection guarantees (subject reduction, progress theorems) hold before, during, and after adaptation, ensuring the absence of communication deadlocks for all reachable system states (Palma et al., 29 Dec 2025).

The approach provides strong correctness guarantees but is limited by the complexity of rulesets (potential rule explosion), lack of built-in error handling primitives for external failures, and the need for middleware resilience layers.

6. Benchmarking and Enhancements over the Reference TeaStore

Adaptable TeaStore introduces robustness, flexibility, and operational resilience absent from the original monolithic design. The key improvements include:

• Configurable Composition: Decomposition into mandatory and optional services allows operation from minimal deployments to multi-region clouds, supporting A/B testing and external resource integration.
• Graceful Degradation: Circuit breakers and local caches avoid complete outages; fallback mechanisms (e.g., anonymous mode for Auth failures) guarantee partial service continuity during disruptions.
• Versatile Deployment: Suitable for on-premise, hybrid, and cloud scenarios; enables integration with third-party authentication (SSO), DaaS, and CDN-based image stores.

Operational outcomes are policy-driven, with reaction and reversion cycles managed algorithmically. Faults trigger local static fallback and automatic restoration of full function, minimizing business impact and obviating code-level intervention.

7. Practical Recommendations and Future Directions

Empirical studies underscore the importance of screening and Bayesian optimization for cost-efficient offline tuning. Adaptable TeaStore practitioners should:

• Define clear adaptation points and scope semantics in choreography and configuration.
• Prefer modular rule hierarchies to manage combinatorial complexity in adaptation logic.
• Isolate non-functional concerns, integrating external controllers for scaling and monitoring.
• Plan for operational resilience via middleware, compensating for limitations in adaptation error handling.
• Leverage by-construction guarantees in choreographic approaches for mission-critical microservices.

Extensions under study include experimental campaigns to benchmark adaptation latency and throughput in realistic cloud deployments, refinement of error correction primitives in choreography, and formal analysis of hybrid control architectures (Bliudze et al., 2024, Truyen et al., 29 Dec 2025, Truyen, 29 Dec 2025, Palma et al., 29 Dec 2025).