Cloud & Serverless: як обрати правильну архітектуру (і не “пересерверлесити”).

Cloud ≠ Serverless. Cloud — це про інфраструктуру як сервіс, Serverless — про події та керований runtime. Найкращі системи зазвичай гібридні: API живе у контейнері, а “спайкові” та важкі задачі — у serverless/чергах.

1) Чому всі говорять про Cloud і Serverless

Сучасні продукти рідко “просто сайт + база”. Вони мають:

• файли (uploads, PDF, images, відео),
• фонові задачі (emails, нотифікації, sync, аналітика),
• інтеграції (CRM, платіжки, webhooks),
• пікові навантаження (реклама, релізи, сезонність).

Класична архітектура “один сервер на все” починає боліти:

• API блокується довгими операціями,
• масштабування складне,
• релізи ризикові,
• інфра стає “ручним мистецтвом”.

Cloud дає керовані будівельні блоки.
Serverless — знімає з нас частину операційної рутини та дає подієвий підхід.

2) Cloud vs Serverless — що це реально означає Cloud (у практиці)

Це набір керованих сервісів:

• DB (Postgres як сервіс),
• Storage (S3),
• Queue (SQS/Redis),
• Email (SES),
• CDN (CloudFront),
• Observability (логи/трейси/метрики).

Ти будуєш систему як з кубиків, але все одно відповідаєш за:

• архітектуру,
• безпеку,
• схеми даних,
• релізи,
• SLO/моніторинг.

Serverless (у практиці)

Це “код, який запускається по події”:

• запит/черга/cron/event,
• автоматичне масштабування,
• оплата за виконання,
• менше devops-рутини.

Але є нюанси:

• cold starts,
• обмеження по часу/пам’яті,
• складніший дебаг,
• інший стиль проєктування (event-driven).

3) Найчастіші помилки в Serverless-підході ❌ 1) Робити serverless “для всього”

Serverless чудово підходить для:

• файлів (resize/compress),
• webhooks ingestion,
• scheduled tasks,
• async jobs,
• event-driven інфраструктури.

Але “все запхати в Lambda” часто закінчується:

• фрагментацією коду,
• хаосом з версіями,
• складним локальним девом,
• непередбачуваним latency.

❌ 2) Відсутність черг і ретраїв

Фонові процеси без queue = випадкові фейли і ручні перезапуски.
Черга — це не “опція”, це страховка та контроль.

❌ 3) Занадто товстий API

Коли API робить PDF, обробляє фото і шле 5 інтеграцій — він стає “повільним монолітом”.

4) Архітектурні рішення: 3 робочі патерни (з аналізом)

Нижче — 3 патерни, які реально працюють у продакшні.

Патерн A: Railway-first MVP (швидко, просто, дешево)

Коли обирати: MVP, стартап, швидкі релізи, невелика команда.

Склад:

• Railway API (Fastify)
• Railway Postgres (Prisma)
• Railway Worker (Node job runner)
• Redis + BullMQ для задач
• AWS S3 для файлів
• AWS SES для листів

Flow:

1. API пише в Postgres
2. API кидає job у Redis/BullMQ
3. Worker виконує: email, PDF, інтеграції
4. Uploads напряму в S3 через presigned URL

Плюси:

• супер швидкий старт
• мінімум інфри
• простий dev experience
• API не блокується

Мінуси:

• Redis/BullMQ — ок для MVP, але на дуже великих масштабах може вимагати уваги
• “enterprise” фічі типу DLQ та складних routing-потоків доведеться будувати або мігрувати

Патерн B: Event-driven backbone на AWS (SQS + Scheduler)

Коли обирати: вже є стабільний трафік, фонова логіка росте, потрібні ретраї та контроль.

Склад:

• Railway API (Fastify)
• Railway Postgres (Prisma)
• AWS SQS (queue)
• AWS EventBridge Scheduler (cron)
• Railway Worker (poll SQS)
• AWS S3, SES
• (опційно) AWS Lambda для file pipeline

Flow:

1. API пише в Postgres
2. API публікує повідомлення в SQS (тип події + payload)
3. Worker читає SQS, виконує, ретраїть, логить
4. Scheduler тригерить регулярні jobs у SQS

Плюси:

• надійність: ретраї, DLQ, контроль
• чітка подієва модель
• легко нарощувати інтеграції
• scheduler “як годинник”

Мінуси:

• більше сервісів → більше дисципліни
• потрібно думати про idempotency

Патерн C: Hybrid “API in containers + serverless for spikes”

Коли обирати: багато файлів/медіа, нерівномірне навантаження, інтеграції, webhooks.

Склад:

• API: Railway (Fastify)
• DB: Railway Postgres
• Storage: S3 (+ CloudFront)
• Lambda: image/pdf processing, webhook ingestion
• SQS: async tasks
• Worker: для довших задач або специфічних інтеграцій

Flow для файлів:

• client → presigned → S3
• S3 event → Lambda → processed assets
• metadata → DB

Плюси:

• ідеально для спайків і медіа
• економія на “пустих” ресурсах
• швидка обробка через події

Мінуси:

• потрібні good practices по спостережуваності
• складніші тести для подійних пайплайнів

5) Рекомендована архітектура під твій стек (Fastify + Prisma + Postgres, AWS + Railway)

Ось “золота середина”, яка стартує як MVP, але має шлях до enterprise:

Базовий старт (MVP)

• Railway: api, worker, postgres
• Redis/BullMQ для задач
• AWS S3 + SES

Коли підеш у масштаб

• міграція черги з Redis → AWS SQS
• додати EventBridge Scheduler
• винести file pipeline у Lambda

Це дає:

• швидкий старт
• планований ріст
• не треба переписувати core

6) Практичні принципи, які рятують у продакшні ✅ 1) API має бути швидким

API: validate → write DB → enqueue → respond.

Все інше — у worker/serverless.

✅ 2) Idempotency скрізь

Події можуть прийти двічі.
Рішення:

• jobId у БД
• unique constraints
• “already processed” checks

✅ 3) Observability не після релізу

Мінімум:

• requestId (кореляція)
• structured logs
• error tracking (Sentry)
• метрики по queue depth / failures

✅ 4) Presigned URLs для uploads

Не ганяй файли через API — це дорогий bottleneck.

7) Висновки: як обрати “свій” Serverless Обирай PaaS-first (platform-first), якщо:

• MVP / швидкі релізи важливіші за ідеальну “cloud-native” архітектуру
• маленька команда, не хочеш витрачати час на DevOps
• потрібен простий dev flow: деплой, логи, env, preview — “з коробки”
• основні задачі — API + база + кілька фонових воркерів/cron

Ідея: стартуємо на керованій платформі (будь-якій) і не ускладнюємо систему завчасно.
Railway тут може бути лише прикладом, так само як Render/Fly.io/Heroku та інші.

Обирай Event-driven (cloud-native) serverless, якщо:

• багато async задач (черги, обробка подій, інтеграції)
• потрібні ретраї, DLQ, контроль виконання, гарантії доставки
• інтеграцій стає більше, і “простий воркер” вже не витягує
• важлива масштабованість і ізоляція компонентів по подіях

Обирай Hybrid, якщо:

• є медіа/файли/пайплайни (upload → processing → delivery)
• навантаження “стрибає”, і хочеш платити за використання, а не за постійний сервер
• потрібно поєднати простоту “одного API” з силою подій/черг/функцій
• хочеш поступово “винести” окремі задачі в serverless без великого рефакторингу

Обирай Railway-first, якщо:

• MVP / швидкі релізи
• маленька команда
• хочеш простий dev flow

Обирай AWS Event-driven, якщо:

• багато async задач
• потрібні ретраї, DLQ, контроль
• інтеграцій стає більше

Обирай Hybrid, якщо:

• медіа, файли, пайплайни
• навантаження “стрибає”
• хочеш економити та масштабуватись автоматично