Ambassador, Sidecar, and Adapter Pattern
Offload everyday tasks for connectivity such as monitoring, routing, logging, and security (usually as a sidecar).
Ambassador Pattern
Strangler pattern
Gradually migrate a legacy system to new applications and services. As functionality moves from the legacy system to the new system, the new system will eventually "strangle" the old one.
Anti-Corruption Layer
Create a facade/adapter layer between different subsystems that do not share the same semantics.
Cache-Aside pattern
Load frequently accessed data into a cache from a data store to improve the application's performance.
Gateway Routing pattern
Simplify the consumption of multiple services by using a single endpoint, that routes requests to the appropriate backend services.
Gateway Offloading pattern
Move specialized and common functionalities to a gateway.
Gateway Aggregation pattern
Use a single service to aggregate multiple individual requests into a single request.
Backends for Frontends pattern
Create a separate backend service for each frontend application or interface.
Materialized View Pattern
Materialized view is a database object that contains the results of a query. Data can be anything from local copy of remote data, complex joins of data, or data calculated with aggregate function.
Event Sourcing
The traditional way of developing a managing entity is to save its current state only. This has to do a lot with hardware limitations we used to have and the basic concept of relational databases that served us very well. However, tables do not represent events that occurred, only the current state of the system. Sometimes it is enough, but not always. What happens if we need more?