pith. sign in

arxiv: 2605.01159 · v1 · submitted 2026-05-01 · 💻 cs.SE · cs.DC

A Domain-Driven Design Simulator for Business Logic-Rich Microservice Systems

Daniel da Palma Pereira , Ant\'onio Rito Silva This is my paper

Pith reviewed 2026-05-09 18:29 UTC · model grok-4.3

classification 💻 cs.SE cs.DC
keywords Domain-Driven DesignmicroservicessimulatorSagastransactional causal consistencybusiness logicdistributed systemsshift-left validation
0
0 comments X

The pith

A DDD-based simulator lets developers test identical microservice business logic code under different consistency models and deployment topologies without building full infrastructure.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces a simulator that models microservice systems around DDD aggregates to separate business logic from infrastructure concerns. This setup lets the same application code run under Sagas, Transactional Causal Consistency, or other guarantees while switching between centralized and fully distributed executions. Developers can therefore measure coordination overhead, performance, and resilience early through deterministic benchmarks on a complex multi-aggregate example. A sympathetic reader would care because the approach reduces the cost of architectural experiments that currently require either production-scale deployments or tools that ignore domain semantics.

Core claim

By modeling microservice systems around aggregates, the simulator isolates core business logic from communication and transactional infrastructure, allowing developers to evaluate identical application code under varying consistency guarantees and network constraints with support for multiple transactional models including Sagas and TCC and seamless transitions across deployment topologies from centralized to fully distributed.

What carries the argument

The DDD microservice simulator that centers systems on aggregates and supplies interchangeable transactional models (Sagas, TCC) plus topology switching.

If this is right

  • The same application code can be benchmarked under multiple consistency guarantees without rewriting coordination logic.
  • Empirical data on coordination overhead and resilience become available before any production infrastructure is provisioned.
  • Seamless transitions between centralized and distributed execution modes allow direct comparison of the same logic in different topologies.
  • Rigorous concurrency testing on a complex multi-aggregate system becomes feasible inside a single deterministic environment.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Teams could integrate the simulator with existing DDD code generators to produce test harnesses automatically.
  • The approach might reduce the frequency of late-stage consistency bugs discovered only after distributed deployment.
  • If simulator results correlate with production traces, the tool could serve as a lightweight oracle for choosing between Sagas and TCC in new services.

Load-bearing premise

Modeling systems around DDD aggregates together with Sagas and TCC inside the simulator produces behavior and performance numbers that match those of real production distributed environments.

What would settle it

Execute the identical multi-aggregate business logic both inside the simulator and on a real distributed deployment with the same input sequences and transactional policies; materially different consistency outcomes or latency distributions would falsify the simulator's claim to provide accurate shift-left validation.

Figures

Figures reproduced from arXiv: 2605.01159 by Ant\'onio Rito Silva, Daniel da Palma Pereira.

Figure 1
Figure 1. Figure 1: Structural architecture of the Microservice Simulator. The Simulator Library acts as a microservices domain-driven design middleware, explicitly decoupling the Application Layer’s domain logic from the underlying Business Layer and Infrastructure Layer. 3. Microservice Simulator The Microservice Simulator3 provides a framework that enables developers to implement business logic using Domain-Driven Design (… view at source ↗
Figure 2
Figure 2. Figure 2: Detailed architecture of the Messaging Module, illustrating the separation between command dispatching (Gateways) and command receiving (Services and Handlers), along with their protocol-specific implementations. from the Application Layer’s domain logic. The module is structured around two primary responsibilities: command dispatching and command handling. Command Dispatching: The dispatching mechanism is… view at source ↗
Figure 3
Figure 3. Figure 3: Architecture of the Notification Module, highlighting the remote-profile event publication/subscription path and the local event persistence services view at source ↗
Figure 4
Figure 4. Figure 4: Architecture of the Impairment Module, illustrating the controller-service delegation and the interaction with the Impairment Generator and the Impairment Handler singleton for testing performance delays and fault tolerance. of these complex failure interleavings. The Impairment Module is an infrastructure component dedicated to fulfilling these objectives by testing the performance delays and fault￾tolera… view at source ↗
Figure 5
Figure 5. Figure 5: Architecture of the Monitoring Module, depicting the controller-service-singleton pattern used to manage tracing across the system view at source ↗
Figure 6
Figure 6. Figure 6: Detailed architecture of the Versioning Module, illustrating the IVersion Service interface and its three specific implementations, alongside the remote command dispatching mechanism integrated with the Messaging Module. defines core operations for version retrieval and manipu￾lation, namely getVersionNumber(), getNextVersionNumber(), and incrementAndGetVersionNumber(). To accommodate different architectur… view at source ↗
Figure 7
Figure 7. Figure 7: Architecture of the Aggregate Module, showing the core Aggregate abstraction, identity generation services, event subscription model, and integration points with event handling. Module by utilizing the Command Gateway to dispatch ver￾sioning requests as commands. Specifically, it sends Get Version Command, Get Next Version Command, Increment Version Command, and Decrement Version Command. On the receiving … view at source ↗
Figure 8
Figure 8. Figure 8: Architecture of the Coordination Module, highlighting the components responsible for structuring, scheduling, and executing domain functionality workflows and their integration with the Transaction, Monitoring, and Impairment modules. is delegated to the Notification Module the persistence and routing of aggregate’s events. 3.7. Coordination Module To address RQ1 (facilitating DDD experimentation) and RQ2 … view at source ↗
Figure 9
Figure 9. Figure 9: Architecture of the Transaction Module, detailing the required extensions to the Aggregate, the application of the Unit of Work pattern, and the extension of the Messaging Module to add transactional qualities to the microservices invocations. protocols must be completely abstracted from the applica￾tion’s business rules. The Transaction Module is the cen￾tral component dedicated to fulfilling these requir… view at source ↗
Figure 10
Figure 10. Figure 10: The architecture of the Application Domain Module illustrates the Tournament aggregate, demonstrating how Domain￾Driven Design (DDD) concepts, such as Entities, Value Objects, Factories, and Services, operate alongside Upstream-Downstream relationships within the simulator. Furthermore, this module details the implementation of the two transactional models within the microservice architecture. • Remote Co… view at source ↗
Figure 11
Figure 11. Figure 11: Architecture of the Application Functionality Module, illustrating how a specific business process (e.g., Add Participant Functionality Sagas) extends the Workflow Functionality base class to orchestrate domain logic using steps and remote commands. 1 public void buildWorkflow ( Integer tournamentAggregateId , Integer executionAggregateId , Integer userAggregateId , 2 SagaUnitOfWork unitOfWork ) { 3 this … view at source ↗
Figure 12
Figure 12. Figure 12: Architecture of the Centralized Local Deployment topology, depicting a centralized execution environment where all aggregates communicate in-memory and share a single centralized database. Similarly, asynchronous communication allows for parallel command execution based on data dependencies, which significantly influences the overall design. For example, an asynchronous model typically returns an immediat… view at source ↗
Figure 13
Figure 13. Figure 13: Architecture of the Centralized Stream Deployment topology, introducing a Message Broker (RabbitMQ) for inter-service communication while maintaining a shared, centralized application database. It also highlights the initialization-time alternative between a standalone database-backed Versioning Application and an in-memory decentralized Snowflake ID generator view at source ↗
Figure 14
Figure 14. Figure 14: Architecture of the Centralized gRPC Deployment topology. It utilizes a gRPC server for point-to-point command communication, while retaining RabbitMQ exclusively for event broadcasting. The shared :Application DB and versioning alternatives remain identical to the Stream topology. Additionally, it incorporates :Service Discovery server (e.g., Eureka) to register and resolve network locations, including i… view at source ↗
Figure 15
Figure 15. Figure 15: Architecture of the Distributed Stream Deployment topology. This fully decentralized configuration features independent microservices (e.g., ms1, ms2) with isolated databases, communicating entirely via a :Message Broker (RabbitMQ) queues. :Service Discovery (Eureka) is utilized for initial routing, while traces are aggregated centrally via Jaeger. 5.7. Containerized Deployments To bridge the gap between … view at source ↗
Figure 16
Figure 16. Figure 16: Architecture of the Distributed gRPC Deployment topology. In this fully decentralized model, isolated microservices execute remote commands via point-to-point gRPC Remote Procedure Calls (RPCs) resolved through a :Service Discovery (Eureka). A :Message Broker (RabbitMQ) is retained exclusively for broadcasting domain events. • Root Configuration: A common docker-compose.yml file at the repository root def… view at source ↗
read the original abstract

Developing business-logic-rich microservices requires navigating complex trade-offs between data consistency and distributed coordination. Although patterns like Sagas and Transactional Causal Consistency (TCC) provide mechanisms to manage distributed state, validating their behavior before production is challenging. Current architectural simulators prioritize network metrics over domain semantics, whereas industry frameworks demand full-scale infrastructure deployments, preventing early architectural experimentation. To bridge this gap, we introduce a \textit{Domain-Driven Design} (DDD) microservice simulator that isolates core business logic from communication and transactional infrastructure. By modeling microservice systems around aggregates, the simulator allows developers to evaluate identical application code under varying consistency guarantees and network constraints. It features support for multiple transactional models (Sagas, TCC) and seamless transitions across diverse deployment topologies, ranging from centralized execution to fully distributed environments. We validate the simulator through the implementation and rigorous concurrency testing of a complex, multi-aggregate microservice system. Through empirical benchmarks, we quantify the performance, coordination overhead, and resilience of different transactional models across localized and distributed execution environments. The findings confirm that the simulator minimizes developer effort while providing a powerful, deterministic environment for the shift-left validation and optimization of business logic implementation in microservice architectures.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper introduces a Domain-Driven Design (DDD) microservice simulator that models systems around aggregates to isolate business logic from communication and transactional infrastructure. It supports multiple transactional models including Sagas and Transactional Causal Consistency (TCC), enables the same application code to run under varying consistency guarantees and deployment topologies (centralized to fully distributed), and claims validation via implementation of a complex multi-aggregate system plus empirical benchmarks quantifying performance, coordination overhead, and resilience.

Significance. If the simulator's modeling of DDD aggregates and transactional support demonstrably preserves semantics while cutting developer effort relative to full deployments, it would address a genuine gap between network-centric simulators and production-scale infrastructure, enabling earlier shift-left validation and optimization of business logic in microservice architectures.

major comments (2)
  1. [Abstract] Abstract: The central claims that the simulator 'minimizes developer effort' and provides 'powerful, deterministic' validation rest on 'implementation and rigorous concurrency testing of a complex, multi-aggregate microservice system' plus 'empirical benchmarks' quantifying performance, coordination overhead, and resilience. No system description, test harness details, quantitative results, tables, figures, error bars, data selection criteria, or exact metrics are supplied, rendering the evidence uncheckable.
  2. [Validation section] Validation claims: The assertion that modeling around DDD aggregates plus Sagas/TCC support allows identical code to run deterministically across consistency models and topologies while accurately reflecting real-world behavior lacks any concrete demonstration (e.g., lines-of-code comparisons, setup-time metrics, or semantic-preservation tests). This is load-bearing for the paper's core contribution.
minor comments (1)
  1. [Abstract] The abstract is lengthy and could be tightened by moving high-level claims about 'minimizing developer effort' to the body once supporting data are added.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our manuscript describing the DDD microservice simulator. The comments correctly identify areas where additional detail would strengthen the presentation of our validation approach. We address each major comment below and have prepared revisions to the manuscript.

read point-by-point responses

  1. Referee: [Abstract] Abstract: The central claims that the simulator 'minimizes developer effort' and provides 'powerful, deterministic' validation rest on 'implementation and rigorous concurrency testing of a complex, multi-aggregate microservice system' plus 'empirical benchmarks' quantifying performance, coordination overhead, and resilience. No system description, test harness details, quantitative results, tables, figures, error bars, data selection criteria, or exact metrics are supplied, rendering the evidence uncheckable.

    Authors: We agree that the abstract, as a high-level summary, does not supply the detailed evidence needed for immediate verification. We will revise the abstract to incorporate a concise description of the implemented multi-aggregate system, an overview of the test harness, and key quantitative benchmark results including performance metrics, coordination overhead values, and resilience indicators with reference to the corresponding tables and figures in the full text. revision: yes

  2. Referee: [Validation section] Validation claims: The assertion that modeling around DDD aggregates plus Sagas/TCC support allows identical code to run deterministically across consistency models and topologies while accurately reflecting real-world behavior lacks any concrete demonstration (e.g., lines-of-code comparisons, setup-time metrics, or semantic-preservation tests). This is load-bearing for the paper's core contribution.

    Authors: We concur that the validation claims require more explicit supporting demonstrations to be fully convincing. The current manuscript outlines the implementation and testing procedure but does not include the requested concrete metrics. In the revised manuscript we will expand the Validation section with lines-of-code comparisons between simulator and traditional deployments, setup-time measurements across topologies, and semantic-preservation test results confirming that business invariants hold equivalently under different consistency models and deployments. revision: yes

Circularity Check

0 steps flagged

No significant circularity; paper describes a built simulator without derivations, fitted parameters, or self-referential reductions.

full rationale

The manuscript introduces a DDD microservice simulator and asserts validation via implementation of a multi-aggregate system plus empirical benchmarks quantifying performance and overhead. No equations, mathematical derivations, parameter-fitting steps, or uniqueness theorems appear in the text. Claims about minimizing developer effort and enabling deterministic evaluation under varying consistency models are descriptive of the tool's design and asserted outcomes rather than reducing by construction to prior self-citations or input data. Self-citation load-bearing, ansatz smuggling, or renaming of known results are absent. The absence of visible benchmark details or code artifacts affects evidence strength but does not create circularity in any derivation chain.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The contribution rests on the domain assumption that DDD aggregates provide a sufficient abstraction for isolating business logic and that the simulator's transactional models faithfully emulate real distributed behavior.

axioms (1)
  • domain assumption Domain-Driven Design aggregates accurately capture business logic complexities in microservices
    The simulator is explicitly built around aggregates as the core modeling unit.
invented entities (1)
  • DDD Microservice Simulator no independent evidence
    purpose: To isolate and test business logic under varying consistency and network conditions
    The simulator is the primary new artifact introduced by the paper.

pith-pipeline@v0.9.0 · 5513 in / 1089 out tokens · 19897 ms · 2026-05-09T18:29:41.024235+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

48 extracted references · 48 canonical work pages

  1. [1]

    Microservices, 2014

    James Lewis and Martin Fowler. Microservices, 2014

    work page 2014

  2. [2]

    Microservices.IEEE Software, 32(1):116–116, 2015

    Johannes Thönes. Microservices.IEEE Software, 32(1):116–116, 2015

    work page 2015

  3. [3]

    Software Architecture: The Hard Parts

    Neal Ford, Mark Richards, Pramod Sadalage, and Zhamak Dehghani. Software Architecture: The Hard Parts. O’Reilly Media, Inc., 2021

    work page 2021

  4. [4]

    Harvest,yield,andscalabletolerant systems

    ArmandoFoxandEricA.Brewer. Harvest,yield,andscalabletolerant systems. InProceedingsoftheTheSeventhWorkshoponHotTopicsin OperatingSystems,HOTOS’99,page174,USA,1999.IEEEComputer Society

    work page 1999

  5. [5]

    Mendonça, Craig Box, Costin Manolache, and Louis Ryan

    Nabor C. Mendonça, Craig Box, Costin Manolache, and Louis Ryan. The monolith strikes back: Why istio migrated from microservices to a monolithic architecture.IEEE Software, 38(5):17–22, 2021

    work page 2021

  6. [6]

    Shift-left testing the agile way

    Suzanne Miller and Robert Binder. Shift-left testing the agile way. ITEA Test & Evaluation Journal, 38(1):48–54, 2017

    work page 2017

  7. [7]

    Apress, Berkeley, CA, 2019

    Navid Nader-Rezvani.Agile Quality Test Strategy: Shift Left, pages 121–138. Apress, Berkeley, CA, 2019

    work page 2019

  8. [8]

    A complexity metric for microservices architecture migration

    Nuno Santos and António Rito Silva. A complexity metric for microservices architecture migration. In2020 IEEE International Conference on Software Architecture (ICSA), pages 169–178, 2020. Daniel Pereira and António Rito Silva:Preprint submitted to ElsevierPage 31 of 32 A Domain-Driven Design Simulator for Business Logic-Rich Microservice Systems

    work page 2020

  9. [9]

    Hector Garcia-Molina and Kenneth Salem. Sagas. InProceedings of the 1987 ACM SIGMOD International Conference on Management of Data, SIGMOD ’87, page 249–259, New York, NY, USA, 1987. Association for Computing Machinery

    work page 1987

  10. [10]

    Manning Publications Co., 2019

    Chris Richardson.Microservices Patterns. Manning Publications Co., 2019

    work page 2019

  11. [11]

    Hellerstein

    Chenggang Wu, Vikram Sreekanti, and Joseph M. Hellerstein. Trans- actional causal consistency for serverless computing. InProceedings of the 2020 ACM SIGMOD International Conference on Management of Data, SIGMOD ’20, page 83–97, New York, NY, USA, 2020. Association for Computing Machinery

    work page 2020

  12. [12]

    Cure: Strong semantics meets high availability and low latency

    Deepthi Devaki Akkoorath, Alejandro Z Tomsic, Manuel Bravo, Zhongmiao Li, Tyler Crain, Annette Bieniusa, Nuno Preguiça, and Marc Shapiro. Cure: Strong semantics meets high availability and low latency. In2016 IEEE 36th International Conference on Distributed Computing Systems (ICDCS), pages 405–414. IEEE, 2016

    work page 2016

  13. [13]

    Addison Wesley, 2003

    Eric Evans.Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison Wesley, 2003

    work page 2003

  14. [14]

    Domain-driven design for microser- vices:Anevidence-basedinvestigation.IEEETransactionsonSoftware Engineering, 50(6):1425–1449, 2024

    Chenxing Zhong, Shanshan Li, Huang Huang, Xiaodong Liu, Zhikun Chen, Yi Zhang, and He Zhang. Domain-driven design for microser- vices:Anevidence-basedinvestigation.IEEETransactionsonSoftware Engineering, 50(6):1425–1449, 2024

    work page 2024

  15. [15]

    Simblock: A blockchain network simulator

    Yusuke Aoki, Kai Otsuki, Takeshi Kaneko, Ryohei Banno, and Kazuyuki Shudo. Simblock: A blockchain network simulator. InIEEE INFOCOM 2019 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pages 325–329, 2019

    work page 2019

  16. [16]

    A framework of virtualwarroomandmatrixsketch-basedstreaminganomalydetection for microservice systems

    Hongyang Chen, Pengfei Chen, and Guangba Yu. A framework of virtualwarroomandmatrixsketch-basedstreaminganomalydetection for microservice systems. InIEEE Access, volume 8, pages 43413– 43426, 2020

    work page 2020

  17. [17]

    Performance Modeling for Cloud Microservice Applications

    Anshul Jindal, Vladimir Podolskiy, and Michael Gerndt. Performance Modeling for Cloud Microservice Applications. InProceedings of the 2019 ACM/SPEC International Conference on Performance Engineering, ICPE ’19, pages 25–32, New York, NY, USA, 2019. Association for Computing Machinery

    work page 2019

  18. [18]

    In 2019 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), pages 212–222, March 2019

    Yanqi Zhang, Yu Gan, and Christina Delimitrou.µqSim: Enabling Accurate and Scalable Simulation for Interactive Microservices. In 2019 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), pages 212–222, March 2019

    work page 2019

  19. [19]

    PerfSim:APerformanceSimulatorforCloudNativeMicroser- vice Chains.IEEE Transactions on Cloud Computing, 11(2):1395– 1413, April 2023

    Michel Gokan Khan, Javid Taheri, Auday Al-Dulaimy, and Andreas Kassler. PerfSim:APerformanceSimulatorforCloudNativeMicroser- vice Chains.IEEE Transactions on Cloud Computing, 11(2):1395– 1413, April 2023

    work page 2023

  20. [20]

    About eventuate tram

    Eventuate. About eventuate tram. https://eventuate.io/ abouteventuatetram.html. Accessed: 2026-03-05

    work page 2026

  21. [21]

    Axon docs

    Axon. Axon docs. https://docs.axoniq.io/ axon-framework-reference/4.12/. Accessed: 2026-03-05

    work page 2026

  22. [22]

    Temporal docs

    Temporal. Temporal docs. https://docs.temporal.io/. Accessed: 2026-03-05

    work page 2026

  23. [23]

    Conductor docs

    Conductor. Conductor docs. https://docs.conductor-oss.org/index. html. Accessed: 2026-03-05

    work page 2026

  24. [24]

    UniStore: A fault-tolerant marriage of causal and strong consistency

    Manuel Bravo, Alexey Gotsman, Borja de Régil, and Hengfeng Wei. UniStore: A fault-tolerant marriage of causal and strong consistency. In2021 USENIX Annual Technical Conference (USENIX ATC 21), pages 923–937. USENIX Association, July 2021

    work page 2021

  25. [25]

    Faastcc: Efficient transactional causal consistency for serverless computing

    Taras Lykhenko, Rafael Soares, and Luis Rodrigues. Faastcc: Efficient transactional causal consistency for serverless computing. InProceed- ingsofthe22ndInternationalMiddlewareConference,pages159–171, 2021

    work page 2021

  26. [26]

    Highly-available and consistent group collaboration at the edge with colony

    Ilyas Toumlilt, Pierre Sutra, and Marc Shapiro. Highly-available and consistent group collaboration at the edge with colony. InProceedings of the 22nd International Middleware Conference, Middleware ’21, page336–351,NewYork,NY,USA,2021.AssociationforComputing Machinery

    work page 2021

  27. [27]

    A commutative replicated data type for cooperative editing

    Nuno Preguiça, Joan Manuel Marques, Marc Shapiro, and Mihai Letia. A commutative replicated data type for cooperative editing. In29th IEEE International Conference on Distributed Computing Systems, ICDCS 2009, pages 395–403. IEEE, 2009

    work page 2009

  28. [28]

    Conflict-Free Replicated Relations for Multi-Synchronous Database Management at Edge

    Weihai Yu and Claudia-Lavinia Ignat. Conflict-Free Replicated Relations for Multi-Synchronous Database Management at Edge. In IEEE International Conference on Smart Data Services, 2020 IEEE World Congress on Services, Beijing, China, October 2020

    work page 2020

  29. [29]

    Software Architecture: The Hard Parts

    Neal Ford, Mark Richards, Pramod Sadalage, and Zhamak Dehghani. Software Architecture: The Hard Parts. O’Reilly, 2022

    work page 2022

  30. [30]

    Workflow patterns.Distributed and parallel databases, 14:5–51, 2003

    WilMPvanDerAalst,ArthurHMTerHofstede,BartekKiepuszewski, and Alistair P Barros. Workflow patterns.Distributed and parallel databases, 14:5–51, 2003

    work page 2003

  31. [31]

    Addison-Wesley, 2012

    Martin Fowler.Patterns of enterprise application architecture. Addison-Wesley, 2012

    work page 2012

  32. [32]

    Addison-Wesley Professional, 2004

    Eric Evans.Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional, 2004

    work page 2004

  33. [33]

    Design Patterns: Elements of Reusable Object-Oriented Software

    Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1994

    work page 1994

  34. [34]

    The opendc microservice simulator: Design, implementation, and experi- mentation, 2023

    Muhammad Ahsan, Sacheendra Talluri, and Alexandru Iosup. The opendc microservice simulator: Design, implementation, and experi- mentation, 2023

    work page 2023

  35. [35]

    microsim:Microservicessimulator

    YuriShkuro. microsim:Microservicessimulator. https://github.com/ yurishkuro/microsim

    work page

  36. [36]

    Scaling up a cloud microservices simulator

    Abdul Mannan Kanji, Ishita Chaudhary, Rithika Lakshmi Shankar, and Subramaniam Kalambur. Scaling up a cloud microservices simulator. In2022 4th International Conference on Circuits, Control, Communication and Computing (I4C), pages 367–371, 2022

    work page 2022

  37. [37]

    Announcing snowflake

    Ryan King. Announcing snowflake. Twitter Engineering Blog, 2010. Accessed: 2025-06-14

    work page 2010

  38. [38]

    Addison-Wesley, 2003

    Martin Fowler.Patterns of Enterprise Application Architecture. Addison-Wesley, 2003

    work page 2003

  39. [39]

    Ruoyu Su and Xiaozhou Li. Modular monolith: Is this the trend in software architecture? InProceedings of the 1st International Workshop on New Trends in Software Architecture, SATrends ’24, page 10–13, New York, NY, USA, 2024. Association for Computing Machinery

    work page 2024

  40. [40]

    Stepwise migration of a monolith to a microservice architecture: Performanceandmigrationeffortevaluation.PerformanceEvaluation, 164:102411, 2024

    Diogo Faustino, Nuno Gonçalves, Manuel Portela, and António Rito Silva. Stepwise migration of a monolith to a microservice architecture: Performanceandmigrationeffortevaluation.PerformanceEvaluation, 164:102411, 2024

    work page 2024

  41. [41]

    Teastore: A micro-service reference application for benchmarking, modeling and resource management research

    André van Hoorn, Johannes Kroß, Nikolas Herbst, Simon Spinner, Reiner Jung, and Samuel Kounev. Teastore: A micro-service reference application for benchmarking, modeling and resource management research. InProceedingsofthe26thInternationalSymposiumonMod- eling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS), pages 1–6. IEEE, 2018

    work page 2018

  42. [42]

    Deathstarbench: A comprehensive benchmark suite for cloud microservices

    Yu Gan, Guoqiang Zhang, Yu Hu, Parthasarathy Ranganathan, John Keniston, and Stephen Williams. Deathstarbench: A comprehensive benchmark suite for cloud microservices. InProceedings of the 13th USENIXSymposiumonOperatingSystemsDesignandImplementation (OSDI), pages 1–17. USENIX Association, 2019

    work page 2019

  43. [43]

    The network is reliable: An informal survey of real-world communications failures.Queue, 12(7):20–32, 2014

    Peter Bailis and Kyle Kingsbury. The network is reliable: An informal survey of real-world communications failures.Queue, 12(7):20–32, 2014

    work page 2014

  44. [44]

    Why does the cloud stop computing? lessons from hundreds of service outages

    Haryadi S Gunawi, Mingzhe Hao, Riza O Suminto, Agung Laksono, Anang D Satria, Jeffry Adityatama, and Kurnia J Eliazar. Why does the cloud stop computing? lessons from hundreds of service outages. InProceedings of the Seventh ACM Symposium on Cloud Computing, pages 1–16, 2016

    work page 2016

  45. [45]

    Transactional causal consis- tent microservices simulator

    Pedro Pereira and António Rito Silva. Transactional causal consis- tent microservices simulator. InIFIP International Conference on Distributed Applications and Interoperable Systems, pages 57–73. Springer, 2023

    work page 2023

  46. [46]

    Transactionalcausalconsistentmicroser- vices business logic

    PedroManuelLopesPereira. Transactionalcausalconsistentmicroser- vices business logic. Master’s thesis, Instituto Superior Técnico, Uni- versity of Lisbon, 2022. https://fenix.tecnico.ulisboa.pt/cursos/ meic-t/dissertacao/565303595503204

    work page arXiv 2022

  47. [47]

    Simulator for saga implemented microser- vice systems

    Andre Martins Esgalhado. Simulator for saga implemented microser- vice systems. Master’s thesis, Instituto Superior Técnico, University of Lisbon, 2024. https://fenix.tecnico.ulisboa.pt/cursos/meic-a/ dissertacao/1972678479056399

    work page arXiv 2024

  48. [49]

    Microservices simulator perfor- mance analysis enriched evaluated

    Rómulo Baltazar Nicolas Kaidussis. Microservices simulator perfor- mance analysis enriched evaluated. Master’s thesis, Instituto Superior Técnico, University of Lisbon, 2025.https://fenix.tecnico.ulisboa. pt/cursos/meic-t/dissertacao/846778572214961. Daniel Pereira and António Rito Silva:Preprint submitted to ElsevierPage 32 of 32

    work page arXiv 2025