Patterns
API Composition
Resiliance is super important in Composition Patterns.
Over Data only
Similar with Using API Composition Pattern.
Compose information from multiple sources.
Availability - single point of failure.
Data consistency.
Higher latency.
Over Business Rules/Services
Where the API Composition would be a Service Composer that would receive data and run business rules over them, returning after the resulting data.
Strangler Application
A way to decompose Microservices with two rules:
Every new feature will be a microservice.
Segregate small peaces of a monolith as a microservice.
At each interation, the monolithic system shrinks until it selft turns into a microservice.
Difficulties in executing this:
Communication with the monolith.
Team maturity. (DevOps culture)
Data Base. (Segregating/Migrating) (Tip.: Use APM to help)
Each microservice needs an APM from the start.
Metrics. (Which metrics you expect for each microservice)
ACL (Anti-Corruption Layer)
Just like in DDD microservices should use an Anti corruption layer to make services more independent.
In DDD an ACL is an interface, in microservices an ACL is another microservice in the middle.
BFF (Backend for Frontend)
This is a technique used to serve data for specific frontend types, since each type of frontend expects different outputs from APIs.
To do this an ACL (Anti-Corruption Layer) is used to transform data returned from the APIs, depending on the Frontend that requested.
Since APIs services are big and complex, using BFF they don't have to worry about this optimizations.
But this new layer of BFFs will add latency to the requests.
How not to use BFFs
Writing the own API microservice to handle this is a solution if thinking ahead of time.
OR using solutions like GraphQL. Since the each Frontend client can choose the excat data that requests.
The downside to this are GraphQL own limitations and downsides.
Transactional Outbox
This is a pattern to implement in a Microservice architecture, to highly increase Patterns, and avoid that requests don't get lost when microservices in the chain are unavailable. (Or even communication between Services and Queues)
To garantee that if at any step of the chain, the message won't be lost if a certain Microservice is down (Even with Patterns policies), you will have to persist this message in a Database or Queue.
So in the example of the image above, we could deal with:
With Database
DatabaseMS 1 will have a Database specific for persisting these messages.
When MS 1 action starts the Message is persisted, and when MS 1 action ends it deletes from the Database.
Then if communication to MS 2 fails the message is persisted and MS 1 can still retry.
The ideia would be a Database for each MS, but I guess the Database could be global and shared between all of them.
Just think about resilience and the repercussion of this.
With global Queue
QueueJust like in the solution above, messages are produced when arrived in each Microservice, and a consumer runs on each of them, consuming the message as soon they finish.
Secret Manager
A mechanism to store Credentials inside a Microservice environment, so that they are not stored inside Environment Variables or stored inside the Microservices.
This solution makes much easier to automatically rotate these passwords.
Logs
All logs from Microservices should be standardized.
Use OTEL (Open Telemetry) to mask and decouple which tools you use for Logs, Metrics and Telemetry (like New Relic, Datadog, Elastic, etc) from your architecture.
Good practice examples
More information, best practices and examples can be seen in #link_to_OTEL.
Last updated