Відкриті до складних інженерних задач

Складні системи, збудовані як інженерія.

Проєктуємо та будуємо продакшен-платформи, які поєднують Rust, Next.js & PostgreSQL — від доменної архітектури до черг, реального часу й надійного деплою.

FOCUSB2B / Commerce
BACKENDRust · Axum
DATAPostgreSQL 17
FRONTENDNext.js 16
RustAxumTokioSQLxPostgreSQL 17RedisNATS JetStreamMeilisearchMinIO / S3Next.js 16React 19TypeScriptTailwind 4DockerNginxsystemdTelegram Bot API

// що ми робимо

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

01

Доменна архітектура

Модульний моноліт із чистими межами: домен, дані, auth, ціни, склад, імпорти, пошук, нотифікації. Готовий до розділення на сервіси без дублювання логіки.

Bounded contextsМодулі-крейтиGuardrails
02

Backend на Rust

Axum + Tokio + SQLx. Транзакційна цілісність, RBAC, rate-limiting на Redis, health/readiness-проби, аудит — те, що відрізняє прототип від системи.

Axum / TokioSQLxRedis
03

Frontend на Next.js

Next.js 16 + React 19 + Tailwind. Вітрина, кабінет B2B, портал менеджера й адмінка в одному застосунку — з проксі-шаром до API та CSRF-захистом.

App RouterRSCTanStack
04

Дані та цілісність

PostgreSQL як джерело істини. Резерви складу, м’які холди, transactional outbox в одній транзакції з замовленням, staging-таблиці з атомарним swap на імпортах.

OutboxStaging swapSnapshots
05

Реальний час і черги

Живий чат, notification-worker на Rust, планувальник. Розібрана й задокументована пастка спільного getUpdates offset між двома споживачами бота.

NATSWorkersLive chat
06

Деплой і надійність

Nginx + systemd + Docker, Let’s Encrypt, бекапи Postgres і MinIO з ретеншеном і репетицією відновлення. Runbook, health-контракти, політики рестарту.

systemdБекапиRunbook

// у цифрах

Не демо. Реальні системи, що працюють у продакшені.

Типовий масштаб платформи, яку веде команда — об’єктивна міра складності, яку вдається утримувати керованою.

0+
API-ендпоінтів
REST /api/v1 на Rust + Axum
0+
таблиць у схемі
PostgreSQL 17, версійовані міграції
0
ітерацій розробки
задокументовано в логу
0
доменних крейтів
auth · pricing · inventory · imports…
0
сервісів у рантаймі
web · api · worker · kp · bot
0 міс
безперервної еволюції
від архітектури до продакшену

// з чим працює команда

B2B-платформи та commerce-системи під високе навантаження

Будуємо єдині системи, що об’єднують публічну вітрину, кабінет B2B, портал менеджера, склад, ціноутворення, замовлення й резерви, нотифікації, звіти та імпорти навколо однієї бази даних.

ДОМЕН
B2B · Commerce · склад
ПІДХІД
Модульний моноліт
ЯДРО
Rust · Next.js · PostgreSQL
РІВЕНЬ
Продакшен-системи

Складність, яка вирішена інженерно

Шість фрагментів системи, де «працює на демо» ≠ «працює у продакшені».

CHALLENGE 01 / 06

Транзакційний outbox

Рядок notification_outbox пишеться в тій самій транзакції, що й замовлення чи резерв — збій транзакції не породжує «фантомної» нотифікації. Rust-worker забирає pending, шле в Telegram і позначає sent або планує ретрай.

перевірено в продакшені

// як це зібрано

Модульний моноліт із межами, готовими до розділення на сервіси.

Одна кодова база, чисті доменні модулі й спільна бізнес-логіка для вітрини, B2B, адмінки, бота та воркерів.

КЛІЄНТИ
Публічна вітрина
Кабінет B2B
Портал менеджера
Telegram
СЕРВІСИ У РАНТАЙМІ
apps/web
Next.js 16 · вітрина, B2B, адмін
apps/api
Rust · Axum · HTTP / WS / auth
notification-worker
Rust · доставка Telegram
kp-service
Python · рендер PDF
telegram-bot
Python · пошук шин
ДОМЕННІ КРЕЙТИ (crates/*)
domaindbauthpricinginventoryimportssearchnotifications
ІНФРАСТРУКТУРА ДАНИХ
PostgreSQL 17
джерело істини
Redis
rate-limit · кеш
NATS JetStream
події · джоби
Meilisearch
пошук
MinIO / S3
файли · фото · PDF

// інструменти

Стек, підібраний під надійність, а не під хайп.

Backend

06
  • Rust
  • Axum
  • Tokio
  • SQLx
  • Redis
  • NATS JetStream

Frontend

06
  • Next.js 16
  • React 19
  • TypeScript
  • Tailwind 4
  • TanStack Query
  • shadcn/ui

Дані та пошук

04
  • PostgreSQL 17
  • Meilisearch
  • MinIO / S3
  • Версійовані міграції

Платформа

06
  • Docker
  • Nginx
  • systemd
  • Let’s Encrypt
  • Бекапи + restore
  • Health-проби

Інтеграції

04
  • Telegram Bot API
  • Python / FastAPI
  • PDF / XLSX
  • Google Merchant feed

Практики

04
  • RBAC + аудит
  • Rate-limiting
  • Transactional outbox
  • Docs-as-you-go

// як ми працюємо

Дисципліна, яка робить складну систему підтримуваною.

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

01

Документуємо кожну значущу зміну

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

02

База даних — джерело істини

Один каталог, одна БД. Жодних паралельних «істин» у JSON чи зовнішній CMS у рантаймі. Дані мають одне місце, де вони правильні.

03

Файли лишаються керованими

Ліміт 3000 рядків на файл, попередження на 2000. SQL і бізнес-логіка виносяться з роутів у репозиторії та сервіси. Аудит і рефактор — без болю.

04

Деструктивні дії — лише атомарно

Зміни над живою БД проходять через staging-таблиці й атомарний swap. Імпорти пишуть snapshots для відкату. Продакшен не ламається «на льоту».

05

Секрети — поза кодом і git

Токени, паролі, ключі — тільки через env і адмін-панель, ніколи в репозиторії. Перед комітом — скан на бойові значення.

06

Спочатку локально, потім VPS

Логіка, міграції та білди доводяться локально. На сервер лишаються тільки домени, секрети, SSL і сховище — мінімум сюрпризів у продакшені.