From db7a0bfff78e7ff129492441a43183c1d365c3c8 Mon Sep 17 00:00:00 2001 From: Artem Zakirullin 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.