chore: link fix

src/pages/blog/en/what-sits-and-what-fits.md

@@ -78,15 +78,15 @@ The key, here, is understanding the trade-offs:
 
 #### Sit #2: Comprehensive unit testing.
 
-The pursuit of 100% test coverage is another example where pragmatism trumps dogma. While comprehensive testing is valuable, focusing on critical paths — like the checkout flow in an e-commerce app — often delivers more ROI (Return of interest) than exhaustive tests for minor features. In my article, [The Truth About Test Coverage](./the-truth-about-test-coverage), I try to demonstrate how understanding the limits of metrics like coverage leads to better decision-making.
+The pursuit of 100% test coverage is another example where pragmatism trumps dogma. While comprehensive testing is valuable, focusing on critical paths — like the checkout flow in an e-commerce app — often delivers more ROI (Return of interest) than exhaustive tests for minor features. In my article, [The Truth About Test Coverage](/blog/en/the-truth-about-test-coverage), I try to demonstrate how understanding the limits of metrics like coverage leads to better decision-making.
 
 #### Sit #3: Event-driven architecture.
 
 Event-driven architecture (EDA) is a powerful paradigm for building scalable, decoupled systems. However, using events everywhere can lead to unnecessary complexity in small applications. Even in distributed systems, many interactions might be synchronous, making RESTful APIs a more straightforward choice. The opposite is also true: in a monolithic application, finding a use case for asynchronous communication might bring huge value, even if that would mean breaking the "monolith" rule.
 
 #### Sit #4: Contract Testing.
 
-Contract testing is a methodology that ensures APIs adhere to a predefined contract. The standard approach involves manually defining these contracts, which can be time-consuming and error-prone in legacy codebases. Instead, in [Iterative Contract Testing](./iterative-contract-testing), we leveraged API responses themselves to generate contracts dynamically. This ***fit*** reduced overhead while maintaining reliability.
+Contract testing is a methodology that ensures APIs adhere to a predefined contract. The standard approach involves manually defining these contracts, which can be time-consuming and error-prone in legacy codebases. Instead, in [Iterative Contract Testing](/blog/en/iterative-contract-testing), we leveraged API responses themselves to generate contracts dynamically. This ***fit*** reduced overhead while maintaining reliability.
 
 By introducing patterns like optimistic schema updates, we sidestepped the initial burden of mapping every API. While this approach might not suit every scenario, it exemplifies how bending traditional practices can yield substantial benefits in specific contexts.
 
@@ -106,7 +106,7 @@ Over-engineering occurs when solutions are designed with more complexity than ne
 
 ### Strategic Fits in Action.
 
-Conversely, there are scenarios where unconventional approaches shine. In [Asynchronous Batching](./asynchronous-batching), grouping requests in Node.js with Fastify provided a lightweight solution to repetitive tasks, reducing computational waste. While it deviated from traditional REST principles, it delivered exceptional performance improvements.
+Conversely, there are scenarios where unconventional approaches shine. In [Asynchronous Batching](/blog/en/asynchronous-batching), grouping requests in Node.js with Fastify provided a lightweight solution to repetitive tasks, reducing computational waste. While it deviated from traditional REST principles, it delivered exceptional performance improvements.
 
 ### Tracking Technical Debt in Fits Scenarios.
 

src/pages/blog/what-sits-and-what-fits.md

@@ -85,15 +85,15 @@ La chiave qui è comprendere i trade-off:
 
 #### Sit #2: Test unitari completi.
 
-Perseguire il 100% di copertura di test è un altro esempio in cui il pragmatismo vince sul dogmatismo. Sebbene i test completi siano preziosi, concentrarsi sulle parti critiche - come il checkout in un'app e-commerce - spesso offre più ROI (Ritorno sull'investimento) che coprire in modo esaustivo funzionalità minori. Nel mio articolo, La verità sulla test coverage](./la-verita-sulla-test-coverage), cerco di dimostrare come comprendere i limiti di metriche come la coverage possa portare a decisioni migliori.
+Perseguire il 100% di copertura di test è un altro esempio in cui il pragmatismo vince sul dogmatismo. Sebbene i test completi siano preziosi, concentrarsi sulle parti critiche - come il checkout in un'app e-commerce - spesso offre più ROI (Ritorno sull'investimento) che coprire in modo esaustivo funzionalità minori. Nel mio articolo, La verità sulla test coverage](/blog/la-verita-sulla-test-coverage), cerco di dimostrare come comprendere i limiti di metriche come la coverage possa portare a decisioni migliori.
 
 #### Sit #3: Architettura event-driven.
 
 L'architettura event-driven (EDA) è un paradigma potente per la realizzazione di sistemi scalabili e disaccoppiati. Tuttavia, usare eventi ovunque può portare a una complessità eccessiva in applicazioni di piccole dimensioni. Anche nei sistemi distribuiti, molte interazioni possono essere sincrone, e quindi le RESTful API risulterebbero più semplici. Vale anche il contrario: in un'applicazione monolitica, trovare un caso d'uso per la comunicazione asincrona può portare un grande valore, anche se ciò significherebbe "infrangere" la regola del monolite.
 
 #### Sit #4: Contract Testing.
 
-Il contract testing è una metodologia che assicura che le API rispettino un contratto predefinito. L'approccio standard prevede la definizione manuale di questi contratti, un processo spesso lungo e soggetto a errori nelle codebase legacy. Invece, in [Iterative Contract Testing](./iterative-contract-testing), abbiamo sfruttato direttamente le risposte delle API per generare contratti dinamicamente. Questo adattamento (***fit***) ha ridotto l'overhead mantenendo l'affidabilità.
+Il contract testing è una metodologia che assicura che le API rispettino un contratto predefinito. L'approccio standard prevede la definizione manuale di questi contratti, un processo spesso lungo e soggetto a errori nelle codebase legacy. Invece, in [Iterative Contract Testing](/blog/iterative-contract-testing), abbiamo sfruttato direttamente le risposte delle API per generare contratti dinamicamente. Questo adattamento (***fit***) ha ridotto l'overhead mantenendo l'affidabilità.
 
 Introducendo pattern come l'optimistic schema updates, abbiamo evitato il fardello iniziale di mappare ogni API. Sebbene questo approccio possa non essere adatto a tutti gli scenari, dimostra come piegare le pratiche tradizionali alle proprie necessità possa offrire benefici sostanziali in contesti specifici.
 
@@ -113,7 +113,7 @@ L'over-engineering si verifica quando le soluzioni vengono progettate con una co
 
 ### Fits strategici in azione.
 
-Al contrario, esistono scenari in cui approcci non convenzionali brillano. In [Asynchronous Batching](./asynchronous-batching), raggruppare le richieste in Node.js con Fastify ha fornito una soluzione leggera a task ripetitivi, riducendo gli sprechi di calcolo. Pur deviando dai principi REST tradizionali, ha garantito miglioramenti prestazionali notevoli.
+Al contrario, esistono scenari in cui approcci non convenzionali brillano. In [Asynchronous Batching](/blog/asynchronous-batching), raggruppare le richieste in Node.js con Fastify ha fornito una soluzione leggera a task ripetitivi, riducendo gli sprechi di calcolo. Pur deviando dai principi REST tradizionali, ha garantito miglioramenti prestazionali notevoli.
 
 ### Tenere traccia del debito tecnico quando si utilizzano Fits.