Модель зворотної піраміди

Що таке «модель зворотної піраміди» в архітектурі

Модель зворотної піраміди - це спосіб проектування систем і протоколів, при якому найважливіша і мінімально необхідна інформація/функціональність передається першій і гарантовано, а менш критичні деталі додаються прогресивно і опціонально. Термін запозичує ідею з журналістики (головне - спочатку), але адаптований до інженерних завдань: критичний шлях працює за будь-яких умов, все інше - «шари збагачення».

Інтуїтивна картинка: вузька вершина зверху - це «мінімальний гарантійний контракт» (MGC), нижче - розширення, оптимізації і багаті функції, які система застосовує, якщо є ресурси/сумісність.

Де це застосовується

Мережеві протоколи та API: REST/gRPC/GraphQL, вебхуки, брокери подій.
Потокові канали: WebSocket, SSE, Kafka/NATS, RTC.
Архітектура сервісів: критичний шлях vs. побічні ефекти (аудит, аналітика, кеш-прогрів).
Мобайл/веб-клієнти: спочатку «скелет» UI і ключові дані, потім лінива підвантаження медіа і рекомендацій.
Платіжні та ризик-ланцюжки: авторизація/резервування - у пріоритеті; антифрод/аналіз - асинхронно, з дедлайнами.
Спостережуваність: завжди лог/метрика мінімального рівня; трейс/профілювання - по семплінгу.

Принципи моделі

1. Мінімальний гарантійний контракт (MGC)

Набір полів і операцій, без яких сценарій не має сенсу. Він стабільний, назад-сумісний і проходить першим.

2. Прогресивне збагачення

Додаткові поля/функції поставляються як опціональні розширення (capabilities/feature flags/Negotiation).

3. Деградація без відмови

При перевантаженні або часткової недоступності система відкидає необов'язкові шари, зберігаючи працездатність MGC.

4. Явна пріоритизація і SLA

Для кожного шару - свої SLO (латентність, доступність), черги і класи обслуговування (QoS).

5. Адитивна еволюція схем

Нові поля додаються як nullable/optional, не ламають клієнтів; жорсткі зміни - тільки через нову версію.

6. Спостережуваність по шарах

Метрики і логи маркуються за критичністю: 'core.','enh.','batch.', щоб бачити, чим система жертвує під навантаженням.

Порівняння з «класичною» пірамідою шарів

Класична архітектура (низи - база, верхи - UI) акцентує залежності.
Зворотна піраміда акцентує важливість і порядок доставки: спочатку «core», потім «nice-to-have».

Проектування протоколів за моделлю

1) REST/HTTP

MGC: мінімальний ресурс/ендпоінт та обов'язкові поля.

• Контент-негаціяція ('Accept','Prefer'),
• Параметри'? include = '/'? fields ='для вибіркової деталізації,
• Посилання на «важкі» вкладення (pre-signed URLs) замість інлайну.
• Деградація: при таймауті віддати MGC без вкладених колекцій; 206 Partial Content для великих тіл.
• Версіонування: адитивні поля без зміни старих контрактів; мажорна версія лише для ламаючих змін.

2) gRPC

proto: нові «optional» поля з безпечною нумерацією тегів; не використовувати видалені теги.
Server-side deadlines і per-method QoS (критичні RPC вище пріоритету).
Streaming: перші повідомлення - заголовки/підсумки, потім деталізація чанками.

3) Подієві шини (Kafka/NATS)

Подія-ядро: 'event _ type','id','occurred _ at', мінімальні бізнес-поля.
Збагачення: виносимо в outbox/CDC і окремі теми'-enriched'.
Сумарі спочатку, деталі потім: споживачі можуть завершувати бізнес-процес по ядру, а деталі довантажуються асинхронно.

Патерни, добре поєднуються зі зворотною пірамідою

Critical Path First: відокремлюйте синхронне «обов'язкове» від асинхронних побічних ефектів.
Write-ahead / Outbox: фіксуємо факт події, решта - фонова доставка.
Lazy & Incremental Fetch: пагінація, курсори,'If-Modified-Since '/ETag.
Capabilities Discovery: сервер/клієнт явно повідомляють, які розширення підтримують.
Backpressure & Budgets: дедлайни, ліміти CPU/IO на шар; скасування другорядних завдань під навантаженням.
SLO-Scoped Caching: кешуємо «ядро» агресивніше, збагачення - коротше/тонше.

Алгоритм впровадження

1. Картування сценаріїв: випишіть User Journey і виділіть «момент цінності».
2. Визначте MGC: мінімальні поля/операції для досягнення цінності.
3. Розділіть на шари: `core`, `extended`, `analytics/batch`.
4. Задайте SLO/SLA і QoS для кожного шару.
5. Спроектуйте деградацію: що відкидаємо при N% відмов/зростанні p95?
6. Еволюція схем: політика версій, additive-first.
7. Спостережуваність: теги шарів в метриках/логах/трейсах, алерти на «core».
8. Тестування: хаос-інжиніринг і fault-injection по шарах.
9. Запуск і зворотній зв'язок: включаємо розширення по фічефлагах і розкочуємо по канарці.

Метрики та SLO по шарах

Core: p95/p99 латентності, частка успішних критичних операцій, відмовостійкість при деградації.
Extended: відсоток збагачених відповідей, середній час довантаження.
Batch/Analytics: лаг від реального часу, частка оброблених подій за вікно.
Бізнес-метрики: конверсія до «моменту цінності» при перевантаженні vs. в нормі.

Антипатерни

«Все - core»: розширення стають обов'язковими, деградація стає неможливою.
Ламаючі зміни MGC без нової мажорної версії.
Прихована крихкість: критичний шлях спирається на зовнішні «другорядні» залежності (наприклад, синхронний виклик антифроду).
Неявні розширення: клієнти не знають, що можна увімкнути/вимкнути.
Відсутність observability: система «мовчки» деградує, а ви не бачите, де.

Приклади

А. профіль користувача (REST)

MGC: `id`, `display_name`, `avatar_url`, `tier`.
Розширення: `badges[]`, `social_links[]`, `recent_activity[]` по `?include=`.
Деградація: при таймауті віддати MGC і посилання на збірні ресурси (HATEOAS/URLs).

Б. платіжна авторизація

MGC: результат авторизації (approved/declined),'transaction _ id','amount','currency'.
Розширення: 3DS телеметрія, ризик-скор, гео, партнерська атрибуція - асинхронно по події'payment. authorized`.
Деградація: при збоях аналітики платіж йде, а аудит/скоринг наздоганяє.

В. потокові котирування

MGC: останній «знімок» ціни.
Розширення: глибина склянки, агреговані індикатори - стрімом після снапшота.
Деградація: під навантаженням падає частота оновлень розширень, але снапшот стабільний.

Версіонування та еволюція

Additive-first: нові поля'optional/nullable', старі залишаються.
Semantic Versions: 'v1'для ядра;'v1. x'- розширення;'v2'- коли MGC змінюється.
Контракти в коді: JSON Schema/Protobuf + CI-валідація «не ламаючих» дифів.

Безпека та відповідність

MGC підписаний/автентифікований: мінімальний набір полів має криптографічну цілісність.
Least Privilege: доступ до збагачень окремими скоупами.
PII/фіндані: винесення в розширення, розділення ключів і TTL.

Спостережуваність і налагодження

Префікси метрик: `core. request. duration`, `enh. attach. load_time`, `batch. lag`.
Sampling: 100% логів для core-помилок; семплювання розширень.
Feature flags telemetry: видно, які розширення включені у яких клієнтів.

Чек-лист впровадження (коротко)

• Визначений і задокументований MGC.
• Розширення оголошені через capabilities/flags.
• Налаштовані SLO/QoS/черги по шарах.
• Деградація перевірена хаос-тестами.
• Еволюція схем - тільки адитивно без «ламань».
• Метрики/трейси/логи розділені по шарах.
• Документація для клієнтів про включення розширень.

FAQ

Чи замінює зворотна піраміда шарувату архітектуру?
Ні, ні. Це ортогональний принцип: як доставляти і пріоритизувати функціональність поверх звичних шарів.

Коли не застосовувати?
В офлайн-пакетах, де часткова доставка безглузда (криптопротоколи з атомарністю), або коли всі поля однаково критичні.

Чим відрізняється від «graceful degradation»?
Зворотна піраміда спочатку проектує мінімально достатній контракт і його пріоритети, а не намагається рятувати вже перевантажену систему «після факту».

Підсумок

Модель зворотної піраміди допомагає архітектурі і протоколам залишатися корисними під будь-якими навантаженнями: головне - спочатку і напевно; решта - по можливості. Це підвищує доступність критичного шляху, прискорює виведення фіч і спрощує еволюцію без поломок.