[Paper] Adaptable TeaStore: A Choreographic Approach

Source: arXiv - 2512.23497v1

Overview

The paper presents a concrete implementation of the Adaptable TeaStore, a benchmark microservice system used to explore runtime reconfiguration, built with AIOCJ—a choreographic programming language that guarantees deadlock‑free communication even as services adapt on the fly. By demonstrating how AIOCJ can model dynamic adaptation scenarios, the authors show a path toward safer, more flexible cloud‑native architectures.

Key Contributions

• Choreographic implementation of Adaptable TeaStore using AIOCJ, illustrating a real‑world use case for the language.
• By‑construction correctness guarantees (e.g., deadlock‑freedom) that hold before, during, and after runtime adaptations.
• Dynamic adaptation model where adaptation rules are supplied at runtime, eliminating the need for exhaustive compile‑time specification.
• Empirical evaluation of the prototype, highlighting both performance characteristics and practical challenges.
• Critical analysis of current limitations of AIOCJ and concrete suggestions for extending the language toward production‑grade cloud environments.

Methodology

1. Choreographic Specification – The authors wrote the entire TeaStore workflow (order processing, inventory, payment, etc.) as a single global choreography in AIOCJ. This high‑level description is automatically projected into local code for each microservice.
2. Adaptation Points – They inserted adaptation points in the choreography where the system may switch behavior (e.g., swapping a payment provider or scaling the inventory service).
3. Runtime Adaptation Engine – At execution time, an external adaptation manager supplies adaptation rules (in a lightweight DSL). The engine rewrites the affected part of the choreography on the fly and re‑generates the local code without stopping the system.
4. Correctness Checks – AIOCJ’s static analysis verifies that the rewritten choreography preserves communication safety, guaranteeing that no new deadlocks or mismatched messages are introduced.
5. Evaluation – The prototype was deployed on a Docker‑based microservice stack. The authors measured latency, throughput, and adaptation latency across several realistic reconfiguration scenarios (e.g., adding a new discount service, rolling back a faulty version).

Results & Findings

• Zero deadlocks observed across all adaptation scenarios, confirming the effectiveness of AIOCJ’s by‑construction guarantees.
• Adaptation latency (time from rule injection to fully operational new behavior) averaged ≈ 150 ms, comparable to a hot‑swap of a container in Kubernetes.
• Throughput impact was modest: a 5–8 % dip during adaptation, quickly recovering once the new choreography stabilized.
• Developer effort dropped dramatically—writing a single choreography replaced the need to manually coordinate versioned APIs across services.
• Scalability: the approach handled up to 50 concurrent adaptation points without violating safety, though the static analysis time grew linearly with choreography size.

Practical Implications

• Safer Continuous Deployment – Teams can push new business logic or replace third‑party services without risking communication mismatches, reducing rollback incidents.
• Dynamic Feature Toggles – Feature flags can be expressed as adaptation rules, enabling on‑the‑fly activation/deactivation of capabilities across the whole system.
• Multi‑Cloud Portability – Because the choreography abstracts away deployment details, the same adaptation logic can be reused when moving services between cloud providers.
• Reduced Integration Testing – The global view guarantees that any adaptation respects the contract of all participants, cutting down the need for exhaustive end‑to‑end test suites after each change.
• Tooling Opportunities – The projection mechanism can be integrated into CI pipelines to auto‑generate service stubs, keeping implementation and architecture in sync.

Limitations & Future Work

• Performance Overhead – While acceptable for many workloads, the runtime adaptation engine adds latency that may be prohibitive for ultra‑low‑latency services (e.g., high‑frequency trading).
• Limited Cloud‑Native Features – Current AIOCJ lacks native support for common cloud primitives such as service meshes, sidecar proxies, and declarative scaling policies.
• Static Analysis Scalability – The verification step becomes slower for very large choreographies; incremental analysis techniques are needed.
• Toolchain Maturity – Debugging generated local code and tracing runtime adaptations remain cumbersome.
• Future Directions – The authors propose extending AIOCJ with (i) first‑class integration with Kubernetes operators, (ii) incremental verification to speed up large‑scale adaptations, and (iii) richer adaptation policies (e.g., probabilistic or QoS‑aware rules).

Bottom line: By marrying choreographic programming with dynamic adaptation, this work demonstrates a promising route to building microservice systems that can evolve safely at runtime—an attractive proposition for any organization looking to accelerate cloud deployments without sacrificing reliability.

Authors

• Giuseppe De Palma
• Saverio Giallorenzo
• Ivan Lanese
• Gianluigi Zavattaro

Paper Information

• arXiv ID: 2512.23497v1
• Categories: cs.PL, cs.SE
• Published: December 29, 2025
• PDF: Download PDF