Communicate – how Do Systems Communicate with each other?
The last three posts in our series have revolved entirely around the Interact stop. The Communicate stop is very closely related to the Interact stop.
In the first Interact post, the distinction between the Interact and Communicate stops was already made clear. As described there, in this stop we will focus on how systems or subsystems communicate with each other.
What Can I Expect from this Stop?
The following topics are included in the Communicate stop:
However, this stop is not concerned with a rigid selection of communication technologies. Rather, the focus is on flexibly selecting the appropriate means based on the functional (domain) and non-functional requirements (architecture goals).
The most sensible communication technology between two or more subsystems usually results from the chosen transaction patterns, in order to ideally implement distributed business transactions.
It should be noted at this point, of course, that in the course of the Architect stop, with the means of Domain Driven Design, unnecessarily distributed business transactions can already be prevented. The “fallacies of distributed computing” vividly outline why this is extremely useful.
Why should I Stop at this Stop?
This stop helps, in combination with the Architect stop, to identify potentially “dangerous” communication paths and proactively avoid them. This also means that the construction of a distributed monolith can be prevented.
The topic of service mesh has been extensively described in the previous articles. Unfortunately, we often see that a service mesh is used to try to get a distributed monolith under control. In some cases, this is successful thanks to the sophisticated possibilities of a service mesh, but it should be borne in mind that this is merely a fight against symptoms and does not solve the actual cause of the problem.
The resilience of the overall system is improved in certain situations, but by no means in all. This then leads to problem situations at absolutely unexpected times. It is therefore necessary to consider the overall situation in order to find sustainable solutions.
This now closes the circle towards the Interact and Architect stops. Based on the findings from the Architect stop, the appropriate communication technologies and transaction patterns can be selected, the coupling between subsystems can be reduced and, in combination with modern technologies such as a service mesh, the resilience of the overall system can be raised to an extremely high level.
How Does this Stop Work?
A Context Map already provides information on how the communication between subsystems will be represented:
The following Context Map outlines this using a sequence from the film “Back to the Future”. And is intended to illustrate how the Context Map contributes to the consideration of the overall situation:
The second part of the consideration of the overall system is the technical part. This primarily involves finding the appropriate transaction pattern based on the architecture goals and the
Based on this, a comprehensible decision about the use of the concrete communication technology is made possible.
Thus, we would be back at the end of a stop and ready to continue the journey to the next stop. I would be happy to receive your suggestions for the next stop at this point.
Simply send an email to konrad.renner@fullstacks.eu 😉
More Blog Posts
Vienna, October 1, 2025 – FULLSTACKS, the leading provider of DevOps, Observability, Cloud-Native, and Security in the DACH region, is presenting its new brand image as of October 2025. [...]
In modern IT landscapes, transparency is the key to stable, reliable, and efficient services. Lack of visibility often leads to critical incidents being noticed only when they are already [...]
What is Changing? Bitnami is changing the way container images are published and used: Instead of managing dozens of immutable, version-specific Docker tags in the public Bitnami registry, [...]
Vienna, July 25, 2025 – FullStackS has reached an important milestone in its corporate development: As the only partner in the German-speaking region, FullStackS now holds the Splunk [...]
The financial industry is under immense pressure to change. Regulatory requirements such as DORA, the constant demand for digitalization, and the increasing need for cybersecurity and compliance challenge the [...]
Full Transparency. Real-time Overview. Proactive SAP Monitoring. Our SAP monitoring solution combines Splunk ITSI with the SAP-specific monitoring engine CSMon and customized dashboards from our partners Consult/R and [...]
Why are Standardized Pipelines a Game Changer?Maintaining CI/CD pipelines can quickly become confusing and redundant in larger organizations, especially if each project uses its own templates or manual pipeline [...]
FinOps as a Long-Term Lever, not a One-Off Project Many companies have successfully implemented FinOps and realized initial savings potential. However, the real challenge begins afterwards: How can [...]
Orlando, March 11, 2025 – FullStackS is pleased to announce that they were awarded the title of "Cloud Elevate Partner of the Year" at the SUSE Partner Summit [...]
Intro: how FullStackS Sustainably Operationalizes the Topic of "FinOpS" in Companies. Many companies recognize the importance of FinOps, but the real challenge lies in its implementation. Theory and [...]