Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

31.05.2023

Оптимізація критичного шляху

Трохи міркувань з приводу дизайну архітектури навколо критичного шляху. Це така ділянка коду, який викликається найчастіше та містить головну бізнес-логіку вашого сервісу. Наприклад, в Телеграмі критичний шлях — це відправлення повідомлення. Чи є він у вас? Варто замислитись, якщо не знаєте.

• Критичний шлях має проходить через якнайменшу кількість компонентів. Це звучить трохи тривіально. Проте насправді такий підхід йде всупереч класичному дизайну, де відповідальності розподілені по сервісах. Раджу критичний шлях зафіксувати як неподільне ціле, а все інше вже можна розкладати, як зручно. Також критичний шлях — гарний кандидат на винесення в стислий сервіс швидшою мовою програмування, такою, як Golang.

• Все, звідки відбувається читання на критичному шляху, має бути закешоване. Або мати швидкодію та здатність до масштабування, порівняну з кешем. Кеш не обовʼязково має бути довготривалим — навіть кешування на 1 хвилину здатне перетворити високе навантаження в помірне. Потреба тут не стільки у швидкості, навіть, а в надійності.

• Всі некритичні операції запису мають бути приховані за чергою. Взагалі черги — гарний механізм перенесення “тиску” між сервісами. Більш звично бачити чергу у випадку довгих задач. Але на критичному шляху навіть запис в базу може бути надто повільною операцією. Особливо коли потрібно спочатку прочитати старі дані, щоб їх оновити… якщо воно не потрібно для відповіді на запит, прибираємо в чергу.

На останок, не треба всього цього робити з MVP. Достатньо заздалегідь усвідомити, де той критичний шлях пролягатиме. Окрім витрат на передчасну оптимізацію, доробляти вже зоптимізований код завжди складніше.