Skip to content

Commit 5c2c042

Browse files
cardilcardil
committed
Reword the architecture chapter
1 parent f9b6f36 commit 5c2c042

File tree

2 files changed

+95
-56
lines changed

2 files changed

+95
-56
lines changed

‎documentation/modules/ROOT/pages/02-architecture.adoc‎

Lines changed: 63 additions & 56 deletions
Original file line numberDiff line numberDiff line change
@@ -12,10 +12,6 @@ operate asynchronously yet collaboratively. In this section, we explore the
1212
technologies, flow, and structure that make the event mesh architecture
1313
resilient, scalable, and developer-friendly.
1414

15-
The solution employs _Command Query Responsibility Segregation (CQRS)_ to
16-
separate commands and queries. Commands are modeled as asynchronous events and
17-
handled by the event mesh. Queries are synchronous operations safe to retry.
18-
1915
[#tech_stack]
2016
== Technology Stack
2117

@@ -36,34 +32,38 @@ Here's the list of technologies used in this solution and its examples:
3632
[#in_depth]
3733
== An in-depth look at the solution's architecture
3834

39-
Building applications around the Event Mesh is a solution that can be applied
40-
either to existing applications or to greenfield projects. The existing
41-
applications can be divided by their domain boundaries. The divided parts might
42-
become modules, or even external services. Those modules will issue commands,
43-
directed towards the Event Mesh, which will be routed towards the configured
44-
endpoints.
35+
Building applications around the Event Mesh is a solution that can be applied
36+
both to existing and new projects. For existing applications, domain boundaries
37+
can guide the division into modular components, which may evolve into separate
38+
services. These modules will generate commands intended for the _Event Mesh_,
39+
which will then route these events to their designated endpoints. The _Event
40+
Mesh_ will allow for such transition, gradually making the system not only more
41+
responsive but also better suited to the real-world business logic.
4542

4643
=== Problem Analysis
4744

48-
Traditional transactional systems enforce strict consistency, which slows
49-
applications and distorts business logic. In our illustrative Cabs app example,
50-
we must accommodate real-world scenarios, such as exiting a cab, even when
51-
dependent systems (e.g., invoicing) encounter disruptions. Disregarding errors,
52-
which preserve the integrity of existing data, discards the newly generated data
53-
from genuine events. This results in a negative user experience and distorts
54-
the actual business process, leading to potential customer dissatisfaction.
45+
Traditional systems often enforce strict transactional consistency,
46+
which can impede application performance and compromise business logic.
47+
For instance, upon the completion of a ride-sharing service at the end-user's
48+
destination, the system should reliably capture this real-world event, irrespective
49+
of any potential operational disruptions affecting dependent services (e.g.,
50+
invoicing).
51+
52+
In such scenarios, transactional applications typically return an error, resulting
53+
in an adverse user experience and a deviation from the genuine business process,
54+
potentially leading to customer dissatisfaction.
5555

5656
=== Solution Breakdown
5757

58-
The concept of employing the Event Mesh as a central, reliable hub for dispatching
59-
commands, as events, lies at the heart of this solution. This approach aligns
60-
closely with the Command Query Responsibility Segregation (CQRS) pattern, which
61-
distinctly categorizes commands and queries. Commands, in this context, are
62-
modeled as asynchronous events, designed to undergo processing by the event mesh.
63-
On the other hand, queries are synchronous operations, safe to retry, ensuring
58+
The concept of employing the _Event Mesh_ as a central, reliable hub for
59+
dispatching commands, as events, lies at the heart of this solution. This
60+
approach aligns closely with the Command Query Responsibility Segregation
61+
(_CQRS_) pattern, which distinctly categorizes commands and queries. Commands,
62+
in this context, are modeled as asynchronous events, designed to undergo
63+
processing by the _Event Mesh_. On the other hand, queries are synchronous operations, safe to retry, ensuring
6464
no loss of data integrity due to transient errors.
6565

66-
The primary responsibility of the Event Mesh is twofold: firstly, it persists
66+
The primary responsibility of the _Event Mesh_ is twofold: firstly, it persists
6767
the incoming events, thereby maintaining a record of changes in the system's
6868
state. Secondly, it routes these events to their respective endpoints, ensuring
6969
that the appropriate microservices are notified and can subsequently update
@@ -74,7 +74,7 @@ strategy, which it employs when encountering operational failures. This mechanis
7474
ensures that the system retries the operation until it succeeds, thus mitigating
7575
the risk of data loss or system disruption due to transient issues.
7676

77-
By integrating the Event Mesh into the system architecture, several architectural
77+
By integrating the _Event Mesh_ into the system architecture, several architectural
7878
benefits are achieved:
7979

8080
* **Decomposition of the application into independently functioning services**:
@@ -84,60 +84,67 @@ benefits are achieved:
8484
demands.
8585

8686
* **Correction of systemic issues**:
87-
The Event Mesh's error-handling mechanism, through retries and event
87+
The _Event Mesh_'s error-handling mechanism, through retries and event
8888
persistence, aids in minimizing the impact of failures on the end user.
8989
This is crucial as it prevents bugs and outages from becoming visible to
9090
the user, thereby preserving the system's perceived responsiveness.
9191

9292
* **Enhanced system performance**:
9393
The system becomes more responsive, as the end user no longer needs to
9494
wait for multiple, often independent, operations to complete successfully.
95-
The Event Mesh's event-driven model, coupled with the retries and event
95+
The _Event Mesh_'s event-driven model, coupled with the retries and event
9696
persistence, ensures that critical state changes are propagated swiftly and
9797
reliably, thereby improving the overall user experience.
9898

99-
=== Event Mesh Flow
99+
=== _Event Mesh_ Flow
100100

101-
* Events are published as CloudEvents to a Knative's Event Mesh.
101+
* Events are published as _Cloud Events_ to a _Knative_'s _Event Mesh_.
102102
* Triggers route events dynamically to the appropriate endpoints.
103103
* Services process events, update state, and emit new events for downstream
104104
consumers.
105105

106-
image::https://www.plantuml.com/plantuml/svg/VP1DJiCm58JtFiMZ-rmWYwgqeHkeX2WNUBK7Ok4ubdyYzVQuZKbe5TZ5olTcFiqcHFOnTKOyn1OTIC8d0xPLdwBH5iBb_rfgnpRIwWMVBC_qwDoAED3ul4MUBKSzW9u6vES1eRsYMzz_mT-YZS-W3tJeLUwyOdlW23zeYJkK8vyuZ52p5O9bRk687uTYLgrB4zNqcav6XvPsR6GocTsZQ8d2L1aV3slQzVP3-uuKpCNgB1JkEwQpzI_FcjxoL5XgcUvdMioVL4soi-iuIOQcE5N259RYPgKYMNJ-3lfdkMPRqp7s7lJkjQFBvWihR61Lwimt[width=100%]
106+
image::https://www.plantuml.com/plantuml/svg/XPBHhjGW48RlUOgnzzi7wCNcsDGOeySOZG_0qkcMB8NA33MDyTsbb6CNNUCT_FF_tv0PdeYbvp0PyOf7d10coUYrFBd0HbiKTDDsbbvEi5rvdH5cPzPK4yguq4FrPa7By8mqLl1302WtpSvkMlNUIjOBGklT3Nq5al8nshu531WjShZ9L4adyLE8mPaUFLJFMda7X7xH2kalUESZsXDysGs9aRKiHNylMLuauM7lsdjdrvRGTtPnMcbxBR2xYe-mHo23i_TFy4V7Uj1AidQsODyNihuDuIxw0QzIhK0hCKxb68xgwtbEkFrQF34xkbt8Wsgt9hbowjrtUphdtJJmALoCfX5msoozk6glhoFNvvY51hxEiG6cBcBF7OQqIOWSzAI9NpZbSg0sE73zpwuPUehlAeCDV7Q1yO4lZ_w_ldBafVdnK-lpyM4QU8jCeEtWG5vY2lgz98h-ANNyXjyJomfuLCxt99xGzc4olm00[width=100%]
107107

108108
////
109-
Online editor:
110-
https://www.plantuml.com/plantuml/uml/VP1DJiCm58JtFiMZ-rmWYwgqeHkeX2WNUBK7Ok4ubdyYzVQuZKbe5TZ5olTcFiqcHFOnTKOyn1OTIC8d0xPLdwBH5iBb_rfgnpRIwWMVBC_qwDoAED3ul4MUBKSzW9u6vES1eRsYMzz_mT-YZS-W3tJeLUwyOdlW23zeYJkK8vyuZ52p5O9bRk687uTYLgrB4zNqcav6XvPsR6GocTsZQ8d2L1aV3slQzVP3-uuKpCNgB1JkEwQpzI_FcjxoL5XgcUvdMioVL4soi-iuIOQcE5N259RYPgKYMNJ-3lfdkMPRqp7s7lJkjQFBvWihR61Lwimt
109+
Editor: https://www.plantuml.com/plantuml/uml/XPBHpfGm48Nl-nGZz_00N6nMWZ56rnYD3z0jmz9iQR7JOeZntIsK1f1D_hjsvZjdcZEzakFM-LwnTwx37g7d3gtakV5EIOsCdb8FtF8UvgkR1eJ1g6dfCQ6CRo3xCA9sS4FgClZ308Jf1wFdMlPPSoT7XCgQ9zeCEAt7WFtow34Wl7tofRESs5_6MgCQj93TfB062Eqe1TB9lBR1sXByYC3YiTRMKk0RxlYT4svuNUt9kZgQVjAZaKBgny4sLl6LxIQ8nedzt_YhSRAL8kHXzC5xtrZhSmWxwHTyS341JUImZp6Sk--7OR6Br_qJ4r77mXfKDGzPEtbZVklyikwcX6_-hYHrWFDcAL65bO_E5PUWXH9-3c40BbDOr6t0iaa8FcX9aai-n-L0eR2TwTTJasaUtdKKbl3TU8TdBaN_9dUEV8DVFxMuR1-cX8_e2AHk3V1xK44JMopDtrJRRqY9fGfO5COsnDWLTUDxzGy0
111110
112111
@startuml
113-
!theme cerulean-outline
114-
participant "Legacy App" as Legacy
115-
participant "Knative Event Mesh" as Broker
116-
participant "Drivers Module" as FeeService
117-
participant "Database" as DB
118-
119-
activate Legacy
120-
Legacy -> Broker : Publish CalculateFee Event
121-
Broker --> Legacy: Confirm delivery
122-
deactivate Legacy
123-
124-
Broker -> FeeService: Route CalculateFee Event
125-
activate FeeService
126-
FeeService --> Broker: Publish DriverFeeCalculated Event
127-
deactivate FeeService
128-
129-
Broker -> Legacy: Route DriverFeeCalculated Event
130-
activate Legacy
131-
Legacy -> DB: Store Trip Data
132-
deactivate Legacy
112+
!theme materia-outline
113+
skinparam linetype polyline
114+
115+
cloud "Event Mesh" {
116+
component "Knative Broker" as Broker
117+
queue "Kafka" as Kafka
118+
}
119+
120+
folder "Micro services" {
121+
component "Drivers Service" as DriversService
122+
database "Drivers DB" as DriversDB
123+
component "Invoicing Service" as InvoiceService
124+
database "Invoicing DB" as InvoiceDB
125+
component "Notification Service" as NotificationService
126+
}
127+
128+
component "Legacy system" {
129+
component "Legacy App" as Legacy
130+
database "Legacy Database" as DB
131+
}
132+
133+
Legacy -down-> Broker: Publish events
134+
Legacy .right.> DB : Update data
135+
Broker .right.> Kafka : Persist events
136+
DriversService .left.> Broker: Publish events
137+
Broker --> DriversService: Route events
138+
Broker --> InvoiceService: Route events
139+
Broker --> NotificationService: Route events
140+
DriversService ..> DriversDB: Gets info about drivers
141+
InvoiceService ..> InvoiceDB: Update Invoice records
133142
@enduml
134143
////
135144

136-
The diagram illustrates the flow of events between the legacy application, the Knative Event Mesh, the fee calculator service, and the datastore.
137-
138145
=== Supporting Legacy Systems
139146

140-
One of the strengths of an event mesh architecture is its ability to integrate seamlessly with legacy systems, making them more resilient and adaptable. Legacy applications can be retrofitted to produce and consume events through lightweight adapters. For instance:
147+
One of the strengths of an _Event Mesh_ architecture is its ability to integrate seamlessly with legacy systems, making them more resilient and adaptable. Legacy applications can be retrofitted to produce and consume events through lightweight adapters. For instance:
141148

142149
* A monolithic Java application can send events for specific operations, like CompleteTransit, instead of handling all logic internally.
143150
* Event listeners can be introduced incrementally, enabling the legacy app to subscribe to events like DriverFeeCalculated without refactoring its core logic.
@@ -150,7 +157,7 @@ Traditional systems often rely on synchronous calls and transactions, which can
150157

151158
For example, invoicing and notification services in an e-commerce platform can process OrderPlaced events independently, ensuring that downtime in one service does not block the entire order workflow.
152159

153-
Retry mechanisms provided by the event mesh guarantee that transient failures are handled gracefully without data loss.
160+
Retry mechanisms provided by the _Event Mesh_ guarantee that transient failures are handled gracefully without data loss.
154161

155162
[#more_tech]
156163
== More about the Technology Stack

‎documentation/modules/ROOT/pages/03-demo.adoc‎

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,38 @@
99

1010
Include here content related to potential existing demos: blogs, articles, recorded videos, walkthrough guides, tutorials.
1111

12+
image::https://www.plantuml.com/plantuml/svg/VP1DJiCm58JtFiMZ-rmWYwgqeHkeX2WNUBK7Ok4ubdyYzVQuZKbe5TZ5olTcFiqcHFOnTKOyn1OTIC8d0xPLdwBH5iBb_rfgnpRIwWMVBC_qwDoAED3ul4MUBKSzW9u6vES1eRsYMzz_mT-YZS-W3tJeLUwyOdlW23zeYJkK8vyuZ52p5O9bRk687uTYLgrB4zNqcav6XvPsR6GocTsZQ8d2L1aV3slQzVP3-uuKpCNgB1JkEwQpzI_FcjxoL5XgcUvdMioVL4soi-iuIOQcE5N259RYPgKYMNJ-3lfdkMPRqp7s7lJkjQFBvWihR61Lwimt[width=100%]
13+
14+
////
15+
Online editor:
16+
https://www.plantuml.com/plantuml/uml/VP1DJiCm58JtFiMZ-rmWYwgqeHkeX2WNUBK7Ok4ubdyYzVQuZKbe5TZ5olTcFiqcHFOnTKOyn1OTIC8d0xPLdwBH5iBb_rfgnpRIwWMVBC_qwDoAED3ul4MUBKSzW9u6vES1eRsYMzz_mT-YZS-W3tJeLUwyOdlW23zeYJkK8vyuZ52p5O9bRk687uTYLgrB4zNqcav6XvPsR6GocTsZQ8d2L1aV3slQzVP3-uuKpCNgB1JkEwQpzI_FcjxoL5XgcUvdMioVL4soi-iuIOQcE5N259RYPgKYMNJ-3lfdkMPRqp7s7lJkjQFBvWihR61Lwimt
17+
18+
@startuml
19+
!theme materia-outline
20+
participant "Legacy App" as Legacy
21+
participant "Knative _Event Mesh_" as Broker
22+
participant "Drivers Module" as FeeService
23+
participant "Database" as DB
24+
25+
activate Legacy
26+
Legacy -> Broker : Publish CalculateFee Event
27+
Broker --> Legacy: Confirm delivery
28+
deactivate Legacy
29+
30+
Broker -> FeeService: Route CalculateFee Event
31+
activate FeeService
32+
FeeService --> Broker: Publish DriverFeeCalculated Event
33+
deactivate FeeService
34+
35+
Broker -> Legacy: Route DriverFeeCalculated Event
36+
activate Legacy
37+
Legacy -> DB: Store Trip Data
38+
deactivate Legacy
39+
@enduml
40+
////
41+
42+
The diagram illustrates the flow of events between the legacy application, the Knative _Event Mesh_, the fee calculator service, and the datastore.
43+
1244
[#demo-video]
1345
=== Watch a demonstration
1446

0 commit comments

Comments
 (0)