ee4b7305a2
This PR adds all the guides from [Visual Guides](https://bytebytego.com/guides/) section on bytebytego to the repository with proper links. - [x] Markdown files for guides and categories are placed inside `data/guides` and `data/categories` - [x] Guide links in readme are auto-generated using `scripts/readme.ts`. Everytime you run the script `npm run update-readme`, it reads the categories and guides from the above mentioned folders, generate production links for guides and categories and populate the table of content in the readme. This ensures that any future guides and categories will automatically get added to the readme. - [x] Sorting inside the readme matches the actual category and guides sorting on production
1.6 KiB
title, description, image, createdAt, draft, categories, tags
| title | description | image | createdAt | draft | categories | tags | |||
|---|---|---|---|---|---|---|---|---|---|
| Top Eventual Consistency Patterns You Must Know | Explore eventual consistency patterns for distributed database design. | https://assets.bytebytego.com/diagrams/0100-eventual-consistency-patterns-you-must-know.png | 2024-02-15 | false |
|
|
Eventual consistency is a data consistency model that ensures that updates to a distributed database are eventually reflected across all nodes. Techniques like async replication help achieve eventual consistency.
However, eventual consistency can also result in data inconsistency. Here are 4 patterns that can help you design applications.
Event-based Eventual Consistency
Services emit events and other services listen to these events to update their database instances. This makes services loosely coupled but delays data consistency.
Background Sync Eventual Consistency
In this pattern, a background job makes the data across databases consistent. It results in slower eventual consistency since the background job runs on a specific schedule.
Saga-based Eventual Consistency
Saga is a sequence of local transactions where each transaction updates data with a single service. It is used to manage long-lived transactions that are eventually consistent.
CQRS-based Eventual Consistency
Separate read and write operations into different databases that are eventually consistent. Read and write models can be optimized for specific requirements.