A Repository is used to manage aggregate persistence and retrieval. The repository mediates between the data-access layer and the domain.The unit of work pattern keeps track of all changes to aggregates. Once all updates of the aggregates in a scope are completed, the tracked changes are played onto the database in a transaction
Many moons ago I was working on an online eCommerce platform. The platform used to undergo massive traffic spikes periodically. I was trying to implement a distributed counter. I was using a distributed counter because I wanted to be able to increment the counter on multiple servers. CAP Theorem The CAP theorem was proposed by Eric Brewer. CRDT CRDT stands for conflict-free replicated datatype. Conflict-free replicated datatype describe data-types that can be replicated across multiple computation units or nodes, they can be updated concurrently without any coordination, and then merged to get a consistent state. It doesn’t matter in which order you execute operations on the data type or if you repeat operations the result is eventually correct. Each node in a distributed system has its own replica of the CRDT. Each replica can resolve queries in isolation and can also process commands that immediately alter its state. CRDTs they can be concurrently updated across nodes and any conflicts can be resolved sensibly. CRDTs always have a merge function that can take many data entries living on different nodes and merge these automatically into one consistent view of the data, without any coordination between the nodes. CRDTs allow two conflicting updates to be merged. All replicas will converge to the same state when all updates have been delivered. The most important properties of the merge function are that it is symmetric and monotonic. The issue that CRDTs address is conflict resolution when different versions of the structure appear due to network partitions and their eventual repair. For a general data structure, if there are two conflicting versions, the solution is either to choose one (according to some general rules, like take the random one or the latest one, or application-specific logic) or to keep both versions and defer conflict resolution to the client code. CRDTs are conflict-free, that is, the structures are devised so that any conflict is resolved automatically in a way that doesn’t bring any data loss or corruption. ...
Imagine a green, sustainable city, meticulously designed for environmental harmony and efficiency. The city has many distinct localities such as neighborhoods, districts, and even villages with their own identity and cultures. This city boasts an intricate public transport system, with buses, trams, and subways efficiently transporting citizens to their destinations from its various localities. Multiple such cities are connected together in a thriving, fast-paced ecosystem. The cities are also similarly connected in an efficient and sustainable design. Each locality in a city represents a microservice, and each city in this system, a domain operating within the larger ecosystem - the application. In an ideal world, this system not only ensures smooth transit but also maintains each city’s eco-friendly ethos; balancing efficiency with sustainability. But how does this ecosystem manage to keep its vast and varied transport network running so smoothly and eco-consciously, avoiding traffic jams, pollution, and inefficiencies? ...
Sidecar pattern is a single-node pattern made up of two containers. It involves co-locating another container in a node/pod along with the main application container. The application container contains the core logic for the application. The role of the sidecar is to augment and improve the application container, often without the application container’s knowledge. In its simplest form, a sidecar container can be used to add functionality to a container that might otherwise be difficult to add. In addition to being co-located on the same machine, the application container and sidecar container share several resources, including parts of the filesystem, hostname and network, and many other namespaces. The sidecar can be plugged and unplugged from the main application, since it is isolated and cannot impact the application in case it starts misbehaving. ...
Transactional Outbox is a pattern to reliably publish messages without the use of distributed transactions. It uses an Outbox and a message dispatcher to reliably persist state and publish messages.
The Idempotent Consumer pattern provides the necessary safeguards to allows logic wrapped by it to be executed only once. It implements an unique identifier for each message and an idempotent repository.
An API Gateway provides a single and unified API entry point across one or more internal APIs. It mediates, routes, and invokes a respective endpoint after request verification, content filtering, authentication, and authorization.
Circuit breakers help to avoid one failing component tearing down other dependent services in a domino effect. The key idea is for a service to fail fast if a dependent resource is not available, as opposed to waiting for a timeout/error for each service invocation during the period in which the dependent resource is down.
The Reactive Manifesto describes how to design and architect Reactive systems according to your needs.Systems built as Reactive Systems are more Reliable, flexible, loosely coupled, scalable and resilient. This makes them easier to develop and amenable to change. Reactive systems are more tolerant of failure and when failure does occur, they meet it with elegance rather than disaster.
The retry pattern is an extremely important pattern to make applications and services more resilient to transient failures. A transient failure is a common type of failure in a cloud-based distributed architecture. This is often due to the nature of the network itself (loss of connectivity, timeout on requests, and so on). Transient faults occur when services are hosted separately and communicate over the wire, most likely over a HTTP protocol. These faults are expected to be short-lived. Repeating such a request that has previously failed could succeed on a subsequent attempt. ...