Apply suggestions from code review

Co-authored-by: Roland Huß <rhuss@redhat.com>

Author: cardil

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

@@ -18,7 +18,7 @@ Here's the list of technologies used in this solution and its examples:
 * Red Hat supported products
 ** https://www.redhat.com/en/technologies/cloud-computing/openshift[Red Hat OpenShift]
 — Orchestrate containerized applications.
-Based on https://kubernetes.io/[Kuberentes].
+Based on https://kubernetes.io/[Kubernetes].
 ** https://www.redhat.com/en/technologies/cloud-computing/openshift/serverless[Red Hat OpenShift Serverless]
 — Provides the _Event Mesh_ and _Serverless_ capabilities.
 Based on https://knative.dev[Knative] project.
@@ -72,7 +72,7 @@ By embracing an eventual consistency model, the _Event Mesh_ aligns closely with
 Unlike traditional transactional systems that strive for immediate, irreversible consistency, the _Event Mesh_ allows for a more flexible and adaptive approach to data consistency.
 This results in better alignment with business requirements, as it supports scenarios where multiple services collaborate and synchronize their operations, making the whole state eventually consistent, without the constraint of strict, synchronous consistency.
 
-* **Avoidance of systemic issues**:
+* **Improved Resilience**:
 The _Event Mesh_'s error-handling mechanism, through retries and event persistence, aids in minimizing the impact of failures on the end user.
 This is crucial as it prevents bugs and outages from becoming visible to the user, thereby preserving the system's perceived responsiveness.
 
@@ -86,16 +86,16 @@ The event-driven flow enables eventual consistent collaboration and state synchr
 
 A usual flow may look like:
 
-1. An end-user application sends a request, which forms a _Command_ type event, which is transferred to the _Event Mesh_.
+1. An end-user application sends an _HTTP_ request to the _Event Mesh_. Such message can be understood as a _Command_ type event.
 2. The _Event Mesh_ (Broker) persists the event in a queue (e.g. Kafka).
-After successful persistence _Event Mesh_ returns the success information.
+After _Event Mesh_ persists safely the data, it returns a successful _HTTP_ response with the `202 Accepted` return code.
 At this point, the operation could already be considered successful, from the end-user point of view.
 It will eventually settle correctly in all downstream systems.
 3. The _Event Mesh_ routes the event to the appropriate endpoint based on the event's metadata and configured triggering rules.
 4. The endpoints receive the events and process them, updating their internal states and potentially emitting new events for downstream consumers.
 The potential events are transmitted to the _Event Mesh_.
 5. The dispatch loop continues until the event queue is empty and all the events are processed successfully.
-The failures are being automatically retried by the _Event Mesh_ using exponential backoff algorithm by default.
+The failures are automatically retried by the _Event Mesh_, with an increasing pauses between retries to avoid overloading the system.
 
 image::https://img.plantuml.biz/plantuml/svg/TPFDReGW483lFCNKkpw0XytMRDCqxJQRDdq05iULB885j35Dtxs8k2xxSuEPRpvm1jV6KcsxHf07MsE3m51t0gbCLMS5bqZCaSkMQjh0kBL3Yz0gCVWSOK9r9IHFFKeBMpHr0hy4WAccLNAC9Q-IMjuZ55eTKIT0JLWwxBl33Xr2goFr6RyYVuHKIfIe8TbofXKOr3rdQAxa6-tKsi3d17X7Y8MGuqjgwPuQNF1DSKvkYbZw8dl56PU7I3j5yPPsAGZYm5wAtvNb5MUk7qf6xlF4V81hmbdf6nue6y0Cnc9prOQGVMnRhvksqHK3CNzuCUf3B2tLZqnNOIevxBgzuAO676TgPYhJ_53RRELg8OUlrgdH-ybKjm1-XexPkTPoOsTFF1R815OZVUVK84tTlUB273xSmyGRN3oW-zoDPb_0brVDLijJoU4PhG4kAmLqxwgWd58aFjzNdTx1gMCX0XgPqgKXQvIb-_d-0G00[width=100%]
 
@@ -159,9 +159,9 @@ A dead letter sink can also be configured to send events in case they exceed the
 === _Work Ledger_ analogy
 
 A good way of thinking about the _Event Mesh_ and its persistent queue backend is the _Work Ledger_ analogy.
-Like in olden days, the clerk was keeping his to-do work in the _Work Ledger_ (e.g. a tray for paper forms).
+Like in the olden days, the clerk kept his to-do work in the _Work Ledger_ (e.g. a tray for paper forms).
 Then he was picking the next form, and processing it, making changes within the physical file cabinets.
-In case of rare and unexpected issues (e.g. Invoicing dept being unavailable), the clerk would just put the data back onto the _Work Ledger_ to be processed later.
+In case of rare and unexpected issues (e.g. invoicing dept being unavailable), the clerk would just put the data back onto the _Work Ledger_ to be processed later.
 
 The _Event Mesh_ is processing the data in very similar fashion.
 The data is held in the _Event Mesh_ only until the system successfully consumes it.

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

@@ -253,7 +253,7 @@ The last part of the refactoring will be the changes needed in our legacy Java a
 We need to remove the _Drivers_ logic and send events to the _Event Mesh_ instead.
 We also need to accept new events coming from the _Event Mesh_, as the calculated fee will be transmitted as such.
 
-Here's the refactored `+completeTransit+` method:
+Here's the refactored code:
 [source,java]
 ----
 public void completeTransit(UUID requestUUID, AddressDTO destinationAddress) {

documentation/modules/ROOT/pages/developer-resources.adoc

@@ -6,7 +6,7 @@
 
 == Developer Resources
 
-* https://github.com/cardil/cabs-usvc[cardil / cabs-usvc] _(The example code used in this solution)_
+* https://github.com/cardil/cabs-usvc[Demo Source] _(The example code used in this solution)_
 * https://youtu.be/Rc5IO6S6ZOk[youtu.be / Rc5IO6S6ZOk] _(The talk that served a base for this solution)_
 * https://www.redhat.com/en/technologies/cloud-computing/openshift/serverless[Red Hat OpenShift Serverless]
 * https://knative.dev/docs/eventing/event-mesh/[Knative Event Mesh]

documentation/modules/ROOT/pages/index.adoc

@@ -11,7 +11,7 @@ that are often at least as complex as the business they operate in.
 This solution pattern is written to make it obvious and to show simple, yet
 elegant, correct, and comprehensive way of building software, either in
 greenfield or even in legacy projects. This solution leverages the
-https://www.redhat.com/en/technologies/cloud-computing/openshift/serverless[Red Hat Serverless]
+https://www.redhat.com/en/technologies/cloud-computing/openshift/serverless[Red Hat OpenShift Serverless]
 Eventing component, which implements the https://www.redhat.com/en/topics/integration/what-is-an-event-mesh[Event Mesh] pattern.
 
 *Contributors:* https://github.com/cardil[Chris Suszynski]