Спроєктувала багаторівневу морську платформу, розділивши фронтенд Next.js PWA, API на Go (Huma/Fiber) та рівень функцій PostgreSQL, зберігши всю бізнес‑логіку в базі даних.

Ситуація. Продукт мав стати морською платформою — професійна соцмережа, відгуки про компанії, спонсороване навчання, — і продукт був молодий, а це делікатний спосіб сказати, що вимоги ще не раз змінюватимуться. Уникнути треба було архітектури, у якій зміна бізнес‑правила вимагає правок одночасно у фронтенді, API та базі даних. У невеликій кодовій базі, що швидко росте, саме така зв’язаність перетворює правку на два рядки на півдня роботи.

Завдання. Роль архітектора вимагала насамперед вирішити, де житиме кожен вид логіки, і провести межі настільки очевидні, щоб вони витримували тиск, а не розмивалися, щойно комусь забракне часу.

Дія. Зрештою склалися три рівні, кожен з одним завданням. Фронтенд на Next.js відповідає за відображення та інтерактивність і ні за що більше. API на Go — Huma поверх Fiber — навмисно тонкий: він маршрутизує, перевіряє запит, застосовує фільтрацію безпеки та оркеструє виклики, але бізнес‑логіки не містить зовсім. Уся бізнес‑логіка живе у функціях PostgreSQL: вони збирають повний результат і віддають його API, щоб той лише передав його далі. Тож коли змінюється правило, воно змінюється на одному рівні, в SQL, а двом іншим про це знати не потрібно. Межі зафіксовано письмово й надалі обстоювано на рев’ю коду, бо домовленість, дотримання якої ніхто не перевіряє, перестає бути домовленістю.

Результат. Систему й надалі було легко тримати в голові. Бізнес‑логіка зосереджена в одному місці, яке справді можна перевірити, API — нудний адаптер у доброму сенсі слова, а фронтендові байдуже, коли під ним змінюється схема. Саме це розділення дало продуктові змогу й далі обростати функціональністю, а архітектурі — не загнивати потихеньку.