ℹ️ disclaimer This article represented my mental model at the time of writing, but I’m always iterating on it. Coupling and cohesion Cohesion Cohesion is a concept that refers to the degree to which the elements (such as functions, classes, or modules) within a software component or module are related to each other and perform a specific, well-defined, and focused set of tasks (it is a crucial principle for designing maintainable, modular, and understandable software systems)....
Components stability in distributed systems
ℹ️ disclaimer This article represented my mental model at the time of writing, but I’m always iterating on it. Components stability in distributed systems Understanding the stability of components is crucial for making any changes to your system. So, it’s essential to assess a component’s stability using various metrics before proceeding with any modifications. Let’s explore some of these metrics that can aid in measuring stability. Instability metric Instability is a measure of how dependent a component is on other components, and how likely it is to be affected by changes in those components....
Different ways of couplings
ℹ️ disclaimer This article represented my mental model at the time of writing, but I’m always iterating on it. Couplings Temporal coupling Temporal coupling is a concept in software design and architecture that refers to a situation where two or more components or modules in a software system depend on each other with respect to the timing or sequence of their execution. In other words, these components are tightly coupled in terms of when they should be executed, which can lead to various issues in software development and maintenance....
Commands in Event-Driven architecture
ℹ️ disclaimer This article represented my mental model at the time of writing, but I’m always iterating on it. Commands A command is an intention to do, not something that has already happened in the system. Commands provide minimal but enough information for decision-making and can be sent synchronously or asynchronously. Similar to events, commands should adhere to common principles and a structured format: use a verb-like syntax for their naming should include criteria, such as command_id for distinguishing them for idempotence should include criteria, such as command_type for applying actions based on different types (on consumer side for commandBus implementation) may include criteria, such as expected_<entity>_version for applying actions based on CAS (compare-and-swap) operations may include criteria, such as trace_id for enabling tracing capabilities … As example, WithdrawUserWalletCommand:...
Consumer retry logic in Event-Driven architecture
ℹ️ disclaimer This article represented my mental model at the time of writing, but I’m always iterating on it. Consumer retry logic When processing events from any message broker, such as RabbitMQ or Kafka, it’s essential to consider implementing retry logic to handle outages or errors effectively. Retrayable and Non-retrayable exceptions There are two types of exceptions: retrayable - you can try a little bit later, after some time to complete operation non-retrayable - this kind of exceptions can’t be fixed over time The primary benefit of categorizing exceptions into different types is the ability to make decisions based on the specific type of exception....
Delivery guarantee for events
ℹ️ disclaimer This article represented my mental model at the time of writing, but I’m always iterating on it. Delivery guarantee for events When application saves some information about entity to data store and then propogates this changes to a broker (RabbitMQ, Kafka, …) there are two transactions: between application and data store between application and broker So, in case of application failure, network problem between application and a broker or by any other outage, this changes may not be sent to the broker (change will be saved in data store, but not propogated to broker)....
Events communication in Event-Driven architecture
ℹ️ disclaimer This article represented my mental model at the time of writing, but I’m always iterating on it. Events communication in Event-Driven architecture In this article we cover most popular approaches how to organize events communiction in the system. 1. Queus (RabbitMQ, …) In the case of queues, the application sends events to a queue broker, which then transfers these events to all bound queues (fan out), or to a single specified queue....
Events in Event-Driven architecture
ℹ️ disclaimer This article represented my mental model at the time of writing, but I’m always iterating on it. Inhabitants of Event-Driven architecture In Event-Driven architecture there are two main inhabitants: commands - intention to apply some actions / changes events - what already happened in the system Building Event-Driven architecture it’s important to pay a lot of attention to events in the system. They are core elements of data flows, and should be designed properly and with care....