chore: update links to assets

jonaslagoni · Oct 1, 2024 · c4c78c7 · c4c78c7
1 parent a7d70c7
commit c4c78c7
Show file tree

Hide file tree

Showing 5 changed files with 4 additions and 4 deletions.
diff --git a/patterns/CDC.drawio.png → patterns/assets/images/CDC.drawio.png b/patterns/CDC.drawio.png → patterns/assets/images/CDC.drawio.png
diff --git a/patterns/dlq.png → patterns/assets/images/dlq.png b/patterns/dlq.png → patterns/assets/images/dlq.png
diff --git a/patterns/cdc.md b/patterns/cdc.md
@@ -11,7 +11,7 @@ In modern systems, data often lives in different places. Keeping all this data u
 
 This is where **Change Data Capture (CDC)** comes in. CDC tracks changes in a database as they happen and sends those changes to other systems. This means everyone always has the latest information, without having to wait for a batch job to run.
 
-![CDC_architecture](./CDC.drawio.png)
+![CDC_architecture](./assets/images/CDC.drawio.png)
 
 
 ## Key Concepts of CDC
@@ -121,7 +121,7 @@ One common mistake is tying CDC events too closely to your database’s structur
 
 ## Relations with Other Patterns
 
-- This can be used in combination with [ECST pattern](/design-patterns/event-carried-state-transfer/), this enable consumers to update their state or react appropriately without needing to fetch additional data
+- This can be used in combination with [ECST pattern](./event-carried-state-transfer.md), this enable consumers to update their state or react appropriately without needing to fetch additional data
 - If you are dealing with data consistency issues in a microservice architecture, you can use CDC in combination with the [transactional outbox pattern](https://newsletter.systemdesigncodex.com/i/141980437/transactional-outbox-pattern-with-cdc)
 - If you are migrating from a monolith application to a microservice you can use the [CDC-Based Strangler Fig Pattern](https://newsletter.systemdesigncodex.com/i/141980437/cdc-based-strangler-fig-pattern) 
 

diff --git a/patterns/command-query-responsibility-segregation.md b/patterns/command-query-responsibility-segregation.md
@@ -7,7 +7,7 @@ description: Separation between commands and queries
 
 In its most basic form, it's just a separation (segregation) between requests that change data (commands) and requests that query data. For example application 1 handles all the commands and application 2 handles all the queries. Usually because each form has separate performance requirements such as throughput, latency, security, etc.
 
-Because read and write happens in different places, one of the drawbacks is having consistency between queries and commands as they lag behind, also called [eventual consistency](./glossary.md#).
+Because read and write happens in different places, one of the drawbacks is having consistency between queries and commands as they lag behind, also called [eventual consistency](./glossary.md).
 
 Application in charge of processing commands:
 ```json

diff --git a/patterns/dead-letter-queue.md b/patterns/dead-letter-queue.md
@@ -7,7 +7,7 @@ description: Solving Message Processing Failures
 
 ## Introduction
 
-![Dead Letter Queue](./dlq.png)
+![Dead Letter Queue](./assets/images/dlq.png)
 
 
 In any robust messaging system, failures are inevitable. Messages might be malformed, consumers might crash, or processing logic might fail due to unforeseen data anomalies. To handle such scenarios gracefully, the Dead Letter Queue (DLQ) pattern is employed.