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

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

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

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

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