Traditional applications usually use RDB and ORM approach for data persistence. But it has several drawbacks and limitations:

• Object-Relational impedance mismatch.

• Lack of aggregate history.

• Implementing audit logging is tedious and error prone.

• Event publishing is bolted on to the business logic.

If an application potentially may produce too many state changes of aggregate – than it worth to implement snapshots and replay events only from the last snapshot for getting current state.

Managing event schema evolution might be challenging due to not all changes of events are backward compatible (renaming, changing type of field, etc.). Upcaster mechanism resolves this challenge. It works similar to schema migrations for SQL databases. It does not change existing events instead updates individual events from an old version to a newer version. As a result, the application code only ever deals with the current event schema.

Deleting data might be tricky. It's possible to implement soft delete with deletion flag in database. But due to General Data Protection Regulation, a European data protection and privacy regulation that grants individuals the right to erasure. An application must have the ability to forget a user’s personal information, such as their email address. Encryption is one mechanism you can use to solve this problem. Each user has an encryption key, which is stored in a separate database table. The application uses that encryption key to encrypt any events containing the user’s personal information before storing them in an event store. When a user requests to be erased, the application deletes the encryption key record from the database table. The user’s personal information is effectively deleted, because the events can no longer be decrypted.

Querying the event store also might be challenging. Consequently, you must implement queries using the CQRS approach described in chapter 7.

Connect with me on LinkedIn

Aggregates have explicit boundaries

An aggregate is a cluster of domain objects within a boundary that can be treated as a unit. It consists of a root entity and possibly one or more other entities and value objects. Many business objects are modeled as aggregates. Aggregates decompose a domain model into chunks, which are individually easier to understand. They also clarify the scope of operations such as load, update, and delete. These operations act on the entire aggregate rather than on parts of it. An aggregate is often loaded in its entirety from the database, thereby avoiding any complications of lazy loading. Deleting an aggregate removes all of its objects from a database. Aggregates must obey is that a transaction can only create or update a single aggregate.

Publishing domain events

In the context of DDD, a domain event is something that has happened to an aggregate. A domain event is a class with a name formed using a past-participle verb. Usually it contains domain object Id also has metadata, such as the event ID, and a timestamp. It might also have the identity of the user who made the change, because that’s useful for auditing. Approach known as event enrichment is for events to contain information that consumers need. It simplifies event consumers because they no longer need to request that data from the service that published the event. Although event enrichment simplifies consumers, the drawback is that it risks making the event classes less stable. An event class potentially needs to change whenever the requirements of its consumers change. This can reduce maintainability because this kind of change can impact multiple parts of the application. Satisfying every consumer can also be a futile effort. Fortunately, in many situations it’s fairly obvious which properties to include in an event.

Event storming

Event storming is an event-centric workshop format for understanding a complex domain. It involves gathering domain experts in a room, lots of sticky notes, and a very large surface – a whiteboard or paper roll – to stick the notes on. The result of event storming is an event-centric domain model consisting of aggregates and events.

Connect with me on LinkedIn

In reality, even monolithic applications typically don’t use textbook ACID transactions. For example, many applications use a lower transaction isolation level in order to improve performance. Also, many important business processes, such as transferring money between accounts at different banks, are eventually consistent.

The traditional approach to maintaining data consistency across multiple services, databases, or message brokers is to use distributed transactions. The de facto standard for distributed transaction management is the X/Open Distributed Transaction Processing (DTP) Model (X/Open XA—see https://en.wikipedia.org/wiki/X/Open_XA).

XA uses two-phase commit (2PC) to ensure that all participants in a transaction either commit or rollback. An XA-compliant technology stack consists of XA-compliant data- bases and message brokers, database drivers, and messaging APIs, and an interprocess communication mechanism that propagates the XA global transaction ID. Most SQL databases are XA compliant, as are some message brokers.

Actually that is form of synchronous IPC, which reduces availability. To solve the more complex problem of maintaining data consistency in a microservice architecture, an application must use a different mechanism that builds on the concept of loosely coupled, asynchronous services. This is where sagas come in.

Using the Saga pattern to maintain data consistency

Sagas are mechanisms to maintain data consistency in a microservice architecture without having to use distributed transactions. You define a saga for each system command that needs to update data in multiple services. A saga is a sequence of local transactions. Sagas differ from ACID transactions in a couple of important ways, they lack the isolation property of ACID transactions. Also, because each local transaction commits its changes, a saga must be rolled back using compensating transactions.

Coordinating sagas

• Choreography – distribute the decision making and sequencing among the saga participants. They primarily communicate by exchanging events.

• Orchestration – centralize a saga’s coordination logic in a saga orchestrator class. A saga orchestrator sends command messages to saga participants telling them which operations to perform.

Choreography might be difficult to understand, there might be cyclical dependencies and risk of tight coupling. It's often better for more complex sagas use orchestration pattern.

A good way to model a saga orchestrator is as a state machine.

Handling the lack of isolation

The lack of isolation can cause the following three anomalies:

• Lost updates – one saga overwrites without reading changes made by another saga.

• Dirty reads – a transaction or a saga reads the updates made by a saga that has not yet completed those updates.

• Fuzzy/nonrepeatable reads – two different steps of a saga read the same data and get different results because another saga has made updates.

Countermeasures for handling the lack of isolation

The saga transaction model is ACD, and its lack of isolation can result in anomalies that cause applications to misbehave. It’s the responsibility of the developer to write sagas in a way that either prevents the anomalies or minimizes their impact on the business.

Countermeasure: Semantic Lock

When using the semantic lock countermeasure, a saga’s compensatable transaction sets a flag in any record that it creates or updates. The flag indicates that the record isn’t committed and could potentially change.

Countermeasure: Commutative Updates

One straightforward countermeasure is to design the update operations to be com- mutative. Operations are commutative if they can be executed in any order. Consider, for example, a scenario where a saga needs to be rolled back after a compensatable transaction has debited (or credited) an account. The compensating transaction can simply credit (or debit) the account to undo the update. There’s no possibility of overwriting updates made by other sagas.

Countermeasure: Pessimistic View

It reorders the steps of a saga to minimize business risk due to a dirty read.

Countermeasure: Reread Value

A saga that uses this counter- measure rereads a record before updating it, verifies that it’s unchanged, and then updates the record.

Countermeasure: Version File

The version file countermeasure is so named because it records the operations that are performed on a record so that it can reorder them. It’s a way to turn non-commutative operations into commutative operations.

Countermeasure: By Value

It’s a strategy for selecting concurrency mechanisms based on business risk. An application that uses this countermeasure uses the properties of each request to decide between using sagas and distributed transactions. It executes low-risk requests using sagas, perhaps applying the countermeasures described in the preceding section. But it executes high-risk requests involving, for example, large amounts of money, using distributed transactions. This strategy enables an application to dynamically make trade-offs about business risk, availability, and scalability.

Connect with me on LinkedIn

Overview of interprocess communication in a microservice architecture

Synchronous request/response-based communication

• REST

• Binary gRPC or Avro

• Other JSON/XML RPC

Asynchronous, message-based communication

• AMQP

• STOMP

Interaction styles

• One-to-one (Request/response, Asynchronous request/response, One-way notifications)

• One-to-many (Publish/subscribe, Publish/async responses)

API-first design is essential – review the interface definition with the client developers than start implementing.

Backward compatible API changes

• Adding optional attributes to request

• Adding attributes to a response

• Adding new operations Resolve backward incompatible changes with versioning of API and deploying two versions of API at the same time.

Message formats

• Text-based

• Binary

Using REST

Maturity model for REST by Leonard Richardson:

• Level 0: Clients invoke the service by making HTTP POST requests to its sole URL endpoint.

• Level 1: Service supports the idea of resources. To perform an action on a resource, a client makes a POST request that specifies the action to perform and any parameters.

• Level 2: Service uses HTTP verbs to perform actions: GET to retrieve, POST to create, and PUT to update. This enables services to use web infrastructure such as caching for GET requests.

• Level 3: Service is based on the terribly named HATEOAS (Hypertext As The Engine Of Application State) principle. The basic idea is that the representation of a resource returned by a GET request contains links for performing actions on that resource. For example, a client can cancel an order using a link in the representation returned by the GET request that retrieved the order. The benefits of HATEOAS include no longer having to hard-wire URLs into client code.

There are numerous benefits to using REST:

• It’s simple and familiar.

• You can test an HTTP API from within a browser using, for example, the Postman plugin, or from the command line using curl (assuming JSON or some other text format is used).

• It directly supports request/response style communication.

• HTTP is, of course, firewall friendly.

• It doesn’t require an intermediate broker, which simplifies the system’s architecture.

There are some drawbacks to using REST:

• It only supports the request/response style of communication.

• Reduced availability. Because the client and service communicate directly with- out an intermediary to buffer messages, they must both be running for the duration of the exchange.

• Clients must know the locations (URLs) of the service instances. This is a nontrivial problem in a modern application. Clients must use what is known as a service discovery mechanism to locate service instances.

• Fetching multiple resources in a single request is challenging.

• It’s sometimes difficult to map multiple update operations to HTTP verbs.

Using gRPC

gRPC has several benefits:

• It’s straightforward to design an API that has a rich set of update operations.

• It has an efficient, compact IPC mechanism, especially when exchanging large messages.

• Bidirectional streaming enables both RPI and messaging styles of communication.

• It enables interoperability between clients and services written in a wide range of languages.

gRPC also has several drawbacks:

• It takes more work for JavaScript clients to consume gRPC-based API than REST/JSON-based APIs.

• Older firewalls might not support HTTP/2.

Handling partial failure using the Circuit breaker pattern

Whenever one service synchronously invokes another service, it should protect itself using the approach described by Netflix:

• Network timeouts – never block indefinitely and always use timeouts when waiting for a response. Using timeouts ensures that resources are never tied up indefinitely.

• Limiting the number of outstanding requests from a client to a service – impose an upper bound on the number of outstanding requests that a client can make to a particular service. If the limit has been reached, it’s probably pointless to make additional requests, and those attempts should fail immediately.

• Circuit breaker pattern – track the number of successful and failed requests, and if the error rate exceeds some threshold, trip the circuit breaker so that further attempts fail immediately. A large number of requests failing suggests that the service is unavailable and that sending more requests is pointless. After a timeout period, the client should try again, and, if successful, close the circuit breaker.

Service discovery

• Application level service discovery – requires to be reimplemented in every used language

• Platform level service discovery – requires all services belong to a platform

Communicating using the Asynchronous messaging pattern

Implementing the interaction styles using messaging

• Asynchronous request/response

• One-way notification – using the same as in previous point point-to-point channel without response

• Publish/subscribe

• Publish/async responses

Unlike with REST and Open API, there isn’t a widely adopted standard for documenting the channels and the message types. Instead, you need to write an informal document. Generally you need to specify the names of the message channels, the message types that are exchanged over each channel, and their formats

Competing receivers and message ordering

For example, imagine that there are three instances of a service reading from the same point-to-point channel and that a sender publishes orderCreated, orderUpdated, and orderCancelled event messages sequentially. A simplistic messaging implementation could concurrently deliver each message to a different receiver. Because of delays due to network issues or garbage collections, messages might be processed out of order, which would result in strange behaviour. In theory, a service instance might process the orderCancelled message before another service processes the orderCreated message!

A common solution, used by modern message brokers like Apache Kafka and AWS Kinesis, is to use sharded (partitioned) channels. For example each Order event message has the orderId as its shard key. Each event for a particular order is published to the same shard, which is read by a single consumer instance. As a result, these messages are guaranteed to be processed in order.

Handling duplicate messages

• Write idempotent message handlers.

• Track messageIds in separate database table and try to insert in the same transaction (or same table for NoSQL).

Transactional messaging

• Using a database table as a message queue – insert to this table in the same transaction and make consumer reading this table and publishing to message broker. Works reasonable well at low scale.

• For large scale better solution is transactional log tailing pattern (Debezium).

Connect with me on LinkedIn

Some notes which I was doing for myself while was reading the book:

What is an architecture?

The 4+1 View Model of Software Architecture

• Logical view – classes and packages

• Implementation view – modules/packages

• Process view – processes at runtime and IPC (interprocess communication)

• Deployment – how the processes are mapped to machines

• +1 – that animate views. Each scenario describes how the various architectural components within a particular view collaborate in order to handle a request. A scenario in the logical view, for example, shows how the classes collaborate. Similarly, a scenario in the process view shows how the processes collaborate.

Why Architecture Matters

An application has two category of requirements:

• Functional requirements – low impact on architecture (you can implement functional requirements with almost every architecture, even with big ball of mud)

• Quality of service requirements (QoS) – scalability, reliability, maintainability, testability, deployability. Here an architecture is important

Architectural Styles

Logical View

• Layered

• Hexagonal – suitable for microservices

Implementation View

• Monolith

• Microservices

What is a service?

The API of service consists of commands createOrder(), queries findOrderById(), and events OrderCreated. Services have to be loosely coupled by API. Don't couple services with shared libraries which include business logic. Move it to a separate service instead. Despite of the word "micro" is represented in the naming of architecture size isn't useful metric. Service should be capable to be developed by a small team.

Service Decomposition

Patterns for decomposing an application into services:

• Decompose by business capability

• Decompose by subdomain – organizes services around domain-driven design (DDD) subdomains Steps for decomposing an application into services:

1. Creating a high-level domain model

2. Defining system operations

3. Decompose into services by business capability or by subdomain with help of Single Responsibility Principle and Common Closure Principle

4. Assign system operations to services

Obstacles to decomposing an Application into Services

• Network latency

• Synchronous interprocess communication reduces availability

• Maintaining Data consistency across services

• Obtaining a consistence view of the data

• God classes prevent decomposition

Connect with me on LinkedIn