Проєктуємо архітектуру веб-додатків: стек, схеми, кешування

Архітектурні рішення веб-додатків: від ідеї до продакшену

Уявіть: ваш стартап зростає, навантаження подвоюється кожні три місяці, а база даних починає гальмувати. Монолітний додаток, який писали нашвидкуруч, більше не тягне. Замість того щоб переписувати все з нуля, ви наймаєте архітектора. Він дивиться на поточний код, виявляє вузькі місця та пропонує план рефакторингу. Ми робимо те саме — але до того, як система впаде.

Архітектура — це набір рішень, які складно змінити потім. Вибір бази даних, спосіб організації сервісів, стратегія масштабування — кожне рішення закладає межі того, що можна побудувати через рік без переписування. Хороше архітектурне рішення враховує реальні обмеження: розмір команди, очікувані навантаження, бюджет на експлуатацію та швидкість змін продукту.

Наш досвід — 12 років у проєктуванні веб-архітектур та понад 50 успішних проєктів. Ми гарантуємо задокументовані рішення з ADR та планом міграції. Правильно спроєктована архітектура економить до 40% на експлуатації та окупається за 2–3 місяці.

З чого починається проєктування

Перш ніж вибирати технології, потрібно відповісти на структурні питання:

• Характер навантаження визначає стратегію кешування. Read-heavy (новинарний портал) — одна стратегія, Write-heavy (біржа) — інша, Mixed (e-commerce) — третя.
• Допустима затримка. Для торгової платформи 100ms — катастрофа, для CMS — прийнятно.
• Піки трафіку. Black Friday дає 100x навантаження — потрібен autoscaling або буферизація через черги.
• Межі транзакційності. Чи можна розділити базу даних або все зав'язано на ACID.

Шари типового веб-додатку

[Клієнт] ↓ HTTPS [CDN / Edge Cache] ↓ Cache Miss [Load Balancer] ↓ [Додаток — N інстансів] ├── [Кеш — Redis/Memcached] ├── [Черга — RabbitMQ/Kafka] └── [База даних — Primary + Replica] ↓ [Object Storage — S3] 

Кожен шар вирішує одне завдання. CDN — статика та кеш на краю. Load Balancer — розподіл і термінування TLS. Додаток — бізнес-логіка. Redis — гарячі дані та сесії. Черга — асинхронні завдання, які не можна виконати в межах HTTP-запиту.

Моноліт чи мікросервіси: що вибрати?

Стандартне питання, на яке часто дають неправильну відповідь. Моноліт — правильний вибір для більшості нових проєктів з командою до 15–20 осіб. Причини:

• Одна транзакція на кілька агрегатів без saga-патернів.
• Простий деплой і спостережуваність (один процес — один лог).
• Рефакторинг без мережевих контрактів.
• Немає проблеми узгодженості при розподілених даних.

Перехід до мікросервісів виправданий, коли команди працюють над незалежними доменами, деплої починають заважати, і конкретні сервіси потребують різного масштабування (наприклад, сервіс обробки зображень vs CRUD API). За нашими оцінками, мікросервіси дають приріст продуктивності в 1.5–2 рази при правильній декомпозиції.

Моноліт із чіткими межами модулів: src/ ├── modules/ │ ├── catalog/ # продукти, категорії, пошук │ │ ├── domain/ │ │ ├── application/ │ │ └── infrastructure/ │ ├── orders/ # замовлення, кошик, checkout │ ├── users/ # аутентифікація, профілі │ └── notifications/ # email, push, sms └── shared/ ├── events/ # доменні події (для майбутньої декомпозиції) └── infrastructure/ # HTTP клієнт, логгер 

Така структура дозволяє витягти модуль у сервіс, коли це стане необхідним — межі вже проведені.

Чому PostgreSQL — правильний вибір для більшості проєктів?

PostgreSQL вирішує 90% завдань. Реляційна модель, JSONB для гнучких даних, повнотекстовий пошук, партиціювання, реплікація — все з коробки. Починати з PostgreSQL і змінювати при конкретних проблемах — правильна стратегія. Наприклад, PostgreSQL з JSONB обробляє запити до вкладених документів у 2–3 рази ефективніше за MySQL при однаковому навантаженні.

Додаткові сховища за призначенням:

Як спроєктувати схему даних без помилок?

Ранні помилки в схемі даних — найдорожчі. Декілька принципів:

Використовуйте UUID замість serial/bigint для ID, якщо планується горизонтальне масштабування або публічний API. UUID v7 сортований і добре працює як кластерний індекс.

-- UUID v7 генерується в додатку CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), user_id UUID NOT NULL REFERENCES users(id), status TEXT NOT NULL DEFAULT 'draft', total_cents INTEGER NOT NULL, currency CHAR(3) NOT NULL DEFAULT 'RUB', created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); -- Тригер для updated_at (краще ніж в ORM) CREATE TRIGGER set_updated_at BEFORE UPDATE ON orders FOR EACH ROW EXECUTE FUNCTION trigger_set_timestamp(); 

Міграції — тільки вперед, не backward-incompatible. Цикл: додаємо колонку (nullable) → деплоїмо код, який її пише → робимо NOT NULL з DEFAULT → видаляємо стару колонку.

Кешування

Три рівні:

HTTP кеш — для публічних ресурсів. Cache-Control: public, max-age=3600, stale-while-revalidate=86400. CDN кешує на краю, браузер — локально.

Application cache — Redis для даних, які дорого обчислювати. Патерн Cache-Aside:

async function getProduct(id: string): Promise<Product> { const cached = await redis.get(`product:${id}`); if (cached) return JSON.parse(cached); const product = await db.product.findUniqueOrThrow({ where: { id } }); await redis.set(`product:${id}`, JSON.stringify(product), 'EX', 3600); return product; } // Інвалідація при оновленні async function updateProduct(id: string, data: Partial<Product>) { const updated = await db.product.update({ where: { id }, data }); await redis.del(`product:${id}`); // Інвалідуємо залежні ключі await redis.del(`category:products:${updated.categoryId}`); return updated; } 

Query cache — PostgreSQL сам кешує плани запитів. Правильні індекси важливіші за будь-який application-рівень.

Асинхронна обробка

Все, що займає більше 200ms або може впасти, повинно йти в чергу:

• Відправка email
• Генерація PDF/зображень
• Інтеграції з зовнішніми сервісами
• Імпорт даних
• Перерахунок агрегатів

// Патерн: API приймає, ставить у чергу, відповідає 202 app.post('/api/orders/:id/invoice', async (req, res) => { const { id } = req.params; await queue.add('generate-invoice', { orderId: id, userId: req.user.id, }, { attempts: 3, backoff: { type: 'exponential', delay: 2000 }, }); res.status(202).json({ message: 'Рахунок генерується, надішлемо на email' }); }); 

Спостережуваність

Три стовпи: логи, метрики, трасування.

Структуровані логи (Pino). Прив'язуємо request-id до всіх логів у межах запиту. Метрики через Prometheus-формат: /metrics endpoint з RED-метриками (Rate, Errors, Duration) на кожен роут.

Типові помилки при проєктуванні

• Вибір мікросервісів «на майбутнє» без реальної необхідності.
• Відсутність ADR — рішення не документуються, їх складно переглянути.
• Ігнорування обмежень команди та бюджету.
• Пізнє усвідомлення необхідності кешування.

Що входить у проєктування архітектури

Проєктування архітектури — це ітеративний процес. У нашу послугу входить:

• Аналіз вимог та обмежень (2 дні).
• Вибір технологічного стеку з обґрунтуванням (ADR).
• Проєктування схеми даних та міграцій.
• Архітектурна документація у вигляді рішень, що перевіряються.
• План масштабування та кешування.
• Рекомендації щодо спостережуваності (логи, метрики, трейси).

Результат — не Visio-діаграма, а набір рішень, що перевіряються, з обґрунтуванням компромісів. Архітектурний рев'ю існуючого проєкту займає 3–5 днів.

Зв'яжіться з нами, щоб отримати попередню оцінку архітектури вашого додатку. Замовте архітектурне рев'ю — це займе 3–5 днів, і ви отримаєте документований план рефакторингу.