5 помилок, які руйнують продуктивність системи, — і як їх уникнути в проєктуванні архітектури
Криптоніт для software architects
У світі високонавантажених систем рідко трапляються «раптові» проблеми продуктивності. Зазвичай вони зʼявляються неочікувано — у вигляді рішень, які на момент ухвалення здавалися зручними, швидкими або «достатньо добрими». А потім, під першим серйозним піком навантаження, система починає задихатися: росте latency, черги збільшуються, база стає bottleneck’ом, а команда намагається зрозуміти чому.
Ця стаття — про 5 типових помилок, які підривають продуктивність ще на етапі проєктування. Оглянемо помилки, що трапляються навіть у досвідчених командах і коштують найдорожче, коли продукт уже в продакшені.
1. Одномонолітити все
На ранніх етапах хочеться будувати все як «велику єдину систему». Це логічно: є лише один репозиторій, одна база, одна точка входу, мінімум координації між командами. Лише потім виявляється, що такий підхід найчастіше стає причиною критичних проблем із продуктивністю. Чому?
Один трафік → одна база → один сервіс → одна точка болю.
Коли вся система витримує потік запитів, будь-яка її частина може перетворитися на bottleneck. Зростання користувачів не означає зростання пропускної здатності, а лише збільшує тиск на єдиний вузол.
Монолітну систему складно розділити на незалежні частини. Навіть якщо її розгорнути в кількох екземплярах, все одно існують спільні ресурси (БД, кеш, файлове сховище), які не масштабуються разом із сервісом.
Також найменша зміна може гальмувати всю систему. Один невеликий модуль здатен тягнути за собою реліз усього застосунку. В результаті — повільні зміни, постійний ризик зламати щось дотичне та неможливість оптимізувати конкретний підкомпонент без впливу на все інше.
Як цього уникнути
Перш за все, архітектори сегментують домени. Це поділ системи за бізнес-логікою: авторизація, білінг, аналітика, пошук, нотифікації. Кожен домен має свої кордони, свої команди й власні вимоги до продуктивності.
По-друге, на заміну монолітним системам давно прийшла мікросервісна архітектура.
Але не потрібно «мікросервісувати» все. Важливо виділити саме ті частини, які критично впливають на масштабування: heavy-compute, високочастотні ендпоінти, сервіс з піковими навантаженнями.
По-третє, впровадження архітектури потоків (flows) — теж хороша альтернатива монолітній архітектурі. Ви можете розділити систему на незалежні ланцюжки обробки:
Прийом запиту → черга → воркери → постпроцесинг → аналітика.
Кожен етап можна масштабувати окремо, оптимізувати під свій тип навантаження та виявляти проблеми локально, а не в усьому застосунку.
2. Вибір «зручної» БД замість «правильної»
В серці будь-якої системи є база даних. Саме вона часто стає джерелом проблем із продуктивністю. Часом не через слабке залізо чи погану оптимізацію, а через неправильний вибір самої технології. Найпоширеніша помилка — брати те, що команда вже знає, замість того, що відповідає характеру навантаження.
Нашкодити це може в декілька способів:
- MySQL там, де потрібен Redis. Спроба використовувати реляційну базу як кеш або як швидке сховище для сесій неминуче призводить до просідання latency. Реляційні БД просто не створені для мільйонів дрібних, високочастотних операцій на секунду.
- MongoDB там, де потрібна реляційність. Документні БД чудові для гнучких структур. Але якщо вам потрібні транзакції, складні зв’язки та строгі гарантії — документний підхід починає боліти. Паралельно росте складність логіки, яка «імітує» відсутні реляційні механізми.
- База стає вузьким горлечком під час піків. Коли все — кеш, аналітика, логіка, пошук, транзакції — живе в одній базі, будь-який сплеск навантаження може паралізувати всю систему. Навіть найпотужніший сервер не врятує, якщо сама модель використання БД обрана неправильно.
Як цього уникнути
1. Підхід Polyglot persistence
Він полягає у використанні кількох технологій зберігання даних (наприклад, реляційних баз даних, NoSQL-баз даних, графових баз даних тощо) в межах однієї системи для задоволення різних потреб додатка.
Сучасні високонавантажені системи не покладаються на єдине сховище. Натомість існує багато комбінацій, як-от Redis для кешу та швидких операцій, PostgreSQL/MySQL для транзакцій, ClickHouse/BigQuery для аналітики.
2. Вибір бази під тип задачі (OLTP, OLAP, кеш, черги, пошук)
Важливо памʼятати, що не буває універсальної БД. Для кожного типу операцій є своя технологія, а змішування всього в одній системі — гарантований шлях до проблем.
3. Тестування продуктивності до релізу
Важливо робити це перед релізом, а не постфактум, коли все вже зламалося. Спеціалісти проводять синтетичні тести на TPS/RPS, аналізують індекси та блокування, симулюють сценарії Black Friday. Це дозволяє побачити слабкі місця до того, як їх покаже продакшн.
3. Відсутність черг та асинхронної обробки
Синхронна обробка — одне з найбільших табу у високонавантажених системах. Навіть якщо логіка не складна, синхронний підхід робить кожен піковий період критичним. Система стає занадто чутливою до будь-яких затримок, а затримки, як відомо, ніколи не з’являються поодинці. Ламає систему це так:
Все обробляється синхронно → довгі відповіді → тайм-аути → падіння, затримки.
Коли користувацький запит змушує систему виконувати важку або тривалу операцію «прямо зараз», час відповіді закономірно росте. Після цього починаються тайм-аути на клієнті, повторні запити, подвійне навантаження, черги у вебсервері, від яких система падає ще швидше.
Простими словами: під час піків система просто не встигає. Якщо 1000 запитів потребують одночасної обробки, синхронний сервер намагається зробити 1000 речей паралельно замість того, щоб вирівняти навантаження. В результаті навіть короткочасний сплеск трафіку виводить з ладу всю вертикаль: від вебу до бази.
Як цього уникнути
По-перше, архітектори використовують брокери: Kafka, RabbitMQ, SQS, NATS. Черги дозволяють вирівнювати пікове навантаження — шляхом того, що швидко приймають запити й обробляють їх у фоновому режимі.
По-друге, синхронні запити залишають тільки для критичних речей, на кшталт авторизації, checkout, платежів, адже вони мають відбуватися тут і зараз. Решту речей (сповіщення, імпорт/експорт, генерацію файлів, аналітику, вебхуки) переносять на асинхронні потоки.
По-третє, використовують 3 механізми: backpressure, retry policy та dead letter queue. Кожен із них рятує від хаосу.
- Backpressure
Відповідає за контроль пропускної здатності. Суть проста: система відмовляється від надлишкового навантаження, щоб не зламатися повністю.
Так, з цим механізмом API повертатиме помилку 429 або 503 замість того, щоб спробувати обробити зайві запити й померти. Брокер черг обмежуватиме споживачів, якщо вони не встигають, а воркери динамічно зменшуватимуть concurrency, коли збільшуються затримки.
- Retry policy
Retry — це не про «спробувати ще раз», а скоріше про правильну стратегію повторів, яка не перетворить невелику помилку на лавину. Оптимальний retry означає експоненційну затримку між повторними спробами (backoff), джиттер — щоби повтори не відбувались одночасно, обмеження кількості спроб та маркування задачі як довготривалої або «токсичної», якщо вона не виконується.
- Dead Letter Queue (DLQ)
Це спеціальна черга, куди потрапляють задачі, які не вдалось обробити після всіх можливих повторів. DLQ дає можливість ізолювати «погані» повідомлення, аналізувати й фіксити їх окремо та підтримувати стабільність черги навіть за наявності некоректних даних.
4. Нехтування кешуванням (або неправильне кешування)
У системах із великим навантаженням кеш відіграє важливу роль в архітектурі. Якщо його немає або він реалізований неправильно — база даних опиняється на передовій кожного запиту і часто не справляється. Чому?
Запит до БД лишається «джерелом істини» для всього. Коли кожен ендпоінт читає дані напряму з бази, навіть прості операції стають дорогими. Найменший пік трафіку множить навантаження на БД, і вся система зависає на IO, блокуваннях та чергах.
Як цього уникнути
Для розв’язання цієї проблеми є кілька способів.
1. Multi-layer caching, або ж багаторівневе кешування. Виглядає воно так:
CDN → Gateway cache → App cache → DB cache.
- CDN — статичні файли, медіа, часто GET-запити.
- Gateway cache / API Gateway — агресивне кешування публічних даних.
- App-level cache (Redis / Memcached) — бізнес-логіка, результати складних запитів.
- DB cache / матеріалізовані представлення — попередньо підраховані агрегати.
Кожен рівень зменшує навантаження на рівень нижче. Це те, що дозволяє сервісам витримувати мільйони RPS.
2. Cache invalidation strategy (TTL, versioning, soft expiration)
Найскладніше в кешуванні — не просто зберігати дані, а розумно їх протерміновувати. Для цього є кілька підходів:
- TTL (Time To Live) задає час життя запису: дані автоматично видаляються або оновлюються після закінчення цього періоду. Це простий та передбачуваний механізм, але не завжди оптимальний для динамічних даних.
- Versioning — це стратегія, де актуальність визначається не часом, а зміною самої версії ресурсу. Ви змінюєте URL або додаєте хеш (наприклад, app.83af.js), і кеш автоматично сприймає це як новий файл. Усе, що не змінилося, — залишається глибоко закешованим і швидким, а оновлене підтягується миттєво.
- Soft expiration — більш гнучкий варіант. Дані мають «м’який» дедлайн: після його настання кеш може віддати стару копію, але паралельно запустить оновлення у фоновому режимі. Користувач отримує відповідь без затримки, а система — свіжі дані для наступних запитів.
3. Кешування важких обчислень та агрегатів
Складні SQL-запити, joins між великими таблицями, значні обчислення (наприклад, рекомендації або аналіз поведінки) — все це має бути кешоване. Це допомагає системі надавати миттєві відповіді на популярні запити й уникати навантаження з CPU та БД.
5. Відсутність спостережуваності (observability)
Без спостережуваності неможливо вчасно виявити вузькі місця, передбачити пікові навантаження або зрозуміти, чому система гальмує. Якщо немає логів, метрик або трейсингу — навіть прості інциденти перетворюються на «чорні скриньки». Всі дії та помилки залишаються невидимими до моменту масштабного падіння.
Ба більше, без потрібних даних команди реагують на наслідки: прибирають помилки вручну, рестартять сервіси, оптимізують одне місце, а справжній bottleneck залишається. Це призводить до постійних повторюваних інцидентів.
Як цього уникнути
Перш за все, варто звернутися до трьох китів: логів, метрик і трейсингу.
- Логи — деталізують події та дії системи, допомагають відтворити інциденти.
- Метрики — числові показники (CPU, memory, RPS, latency, error rate) для швидкої оцінки стану.
- Трейсинг — дозволяє відстежити шлях запиту через усі сервіси та виявити вузькі місця.
Додатково важливо візуалізувати важливі показники на дашбордах. З найочевиднішого — вам завжди потрібно бачити:
- RPS (requests per second)
- Latency (час відповіді)
- Error rate (частку помилок)
- Saturation (завантаження ресурсів)
Щоб не обпектись через неуважність, спеціалісти часто проводять навантажувальні тестування та SLO/SLA. Тестування під реальним трафіком допомагає прогнозувати проблеми, а SLO/SLA задають очікувані показники: час відповіді, відсоток успішних запитів, uptime.
