Дякую за коментар! Ви підняли надзвичайно цікаву тему. Дійсно, сучасний ринок пропонує розкішні інструменти (NewSQL бази типу CockroachDB, Spanner, або Citus), які обіцяють «шардінг з коробки». Здається, що можна просто налаштувати інфраструктуру — і забути.

Але на практиці ми стикаємося з концепцією «дірявої абстракції» (leaky abstraction).

1. Про ілюзію повної абстракції шардінгу:
Ці інструменти геніально абстрагують інфраструктурний біль (Ops), але вони ніколи не знімають відповідальності з розробника (Dev). Чому?

Проблема Distributed JOINs: Якщо розробник пише код, думаючи, що працює зі звичайною локальною базою, і робить класичний JOIN, розподілена база виконає його. Але якщо дані лежать на різних шардaх (наприклад, у EU та US), база почне ганяти гігабайти даних через океан. Продуктивність впаде до нуля. Розробник мусить знати про шардінг, щоб правильно обрати Shard Key і ко-локувати пов’язані дані на одному вузлі.

Фізика і транзакції: regions=[EU, US] в Terraform означає, що під капотом працюватимуть розподілені транзакції (Two-Phase Commit або консенсус). Швидкість світла не обдуриш — кожна транзакція матиме затримку в десятки мілісекунд. Розробник має адаптувати бізнес-логіку (асинхронність, таймаути), інакше система не виконає SLA.

2. Щодо DWH і «збирати одразу з таких інструментів»:
Тут усе впирається в ROI (Return on Investment). Збирати систему одразу з розподілених баз та DWH — це свідомо обрати найвищий рівень складності розробки з першого дня. Розробникам доведеться враховувати ці «діряві абстракції», писати складніший код і обходити обмеження мережі. Time-to-market різко впаде, а вартість розробки та хмарних ресурсів виросте.

Тому, хоча інструменти існують і вони прекрасні, архітектурне рішення про їх використання (рух по осях Y та Z) має диктуватися реальними проблемами масштабу, а не просто їхньою наявністю.

Дуже гарне зауваження! Дійсно, глибока декомпозиція вимагає зміни коду. Але Operations (DevOps) мають у своєму арсеналі способи рухатися по осях Y та Z суто інфраструктурними методами.
Вісь Y (Декомпозиція):
Навіть якщо ми маємо моноліт, ми можемо імітувати мікросервісний підхід через L7-маршрутизацію (API Gateway / Ingress). Ми розгортаємо кілька пулів нашої аплікації і кажемо маршрутизатору: «Всі запити на /catalog відправляй на пул А, а всі запити на /checkout — на пул Б». Бізнес-логіка єдина, але ресурси під різні функції ізольовані.
Вісь Z (Шардінг):
Як приклад: робота з топологією мережі та сегментацією клієнтів.
Географічна ізоляція: розгортаємо ідентичні кластери в US та EU, а користувачів маршрутизуємо через Geo-DNS.
Ізоляція за SLA (Tenant isolation): виділяємо окремі кластери під різні тарифи (Free, General, Enterprise). Запити від преміум-клієнтів летять на виділене, потужне «залізо». Продукт той самий, але дані та клієнти жорстко сегментовані.
Тому Operations не обмежені лише нарощуванням інстансів/ресурсів (Вісь X). Завдяки грамотній маршрутизації та топології вони можуть виграти для розробників купу часу перед тим, як доведеться реально переписувати код