From db7a0bfff78e7ff129492441a43183c1d365c3c8 Mon Sep 17 00:00:00 2001
From: Artem Zakirullin <artemzr@gmail.com>
Date: Fri, 13 Dec 2024 09:33:51 +0200
Subject: [PATCH] fix rephrase for less distance and better clarity

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 540c192..703ab3e 100644
--- a/README.md
+++ b/README.md
@@ -263,7 +263,7 @@ If you think that such layering will allow you to quickly replace a database or
 > will be depended on by somebody.  
 > [The law of implicit interfaces](https://www.hyrumslaw.com/)
 
-We did a storage migration, and that took us about 10 months. The old system was single-threaded, so the exposed events were sequential. All our systems depended on that observed behaviour. This behavior was not part of the API contract, it was not reflected in the code. A new distributed storage didn't have that guarantee - the events came out-of-order. We spent only a few hours coding a new storage adapter for the existing data abstraction layer. We spent the next 10 months on dealing with out-of-order events and other challenges. It's now funny to say that layering helps us replace components quickly.  
+We did a storage migration, and that took us about 10 months. The old system was single-threaded, so the exposed events were sequential. All our systems depended on that observed behaviour. This behavior was not part of the API contract, it was not reflected in the code. A new distributed storage didn't have that guarantee - the events came out-of-order. We spent only a few hours coding a new storage adapter. We spent the next 10 months on dealing with out-of-order events and other challenges. It's now funny to say that layering helps us replace components quickly.  
 
 **So, why pay the price of high cognitive load for such a layered architecture, if it doesn't pay off in the future?** Plus, in most cases, that future of replacing some core component never happens.