Стартап запускає MVP, а через півроку кодова база перетворюється на спагеті. Розробники бояться торкатися модуля оплати, щоб не зламати авторизацію. Така ситуація знайома багатьом командам — і найчастіше причина в архітектурі, вибраній «на око» без урахування майбутніх сценаріїв. Ми допомагаємо командам прийняти вірне архітектурне рішення на старті або провести аудит існуючої системи. Наш багаторічний досвід показує: правильно спроектована архітектура окупається багаторазово, знижуючи час виведення нових фіч на 30–50% і запобігаючи дорогим помилкам. Залиште заявку, щоб закласти правильну основу.
Як консультація запобігає дорогим помилкам?
Неправильне архітектурне рішення може призвести до значних додаткових трудозатрат. Наприклад, мікросервіси, введені без необхідності, створюють overhead на комунікацію, деплой і моніторинг. Ми аналізуємо предметну область, бізнес-вимоги та сценарії зростання, щоб вибрати оптимальний стиль: моноліт, модульний моноліт або мікросервіси. Результат — план, який знижує вартість доопрацювань і прискорює релізи.
Коли моноліт вигідніший за мікросервіси?
Моноліт — правильний вибір для більшості стартапів і команд до 10 розробників. Немає overhead на міжсервісну взаємодію, простіше дебажити, дешевше в підтримці. За статистикою, 90% проектів на ранній стадії не потребують мікросервісів. Модульний моноліт з чіткими межами — чудова відправна точка. Він дає гнучкість виділення сервісів без переписування всього.
Приклад структури Modular Monolith
src/
modules/
auth/ # Bounded Context: авторизація
domain/
application/
infrastructure/
billing/ # Bounded Context: оплата
notifications/ # Bounded Context: сповіщення
shared/
kernel/ # Загальні примітиви (Money, UserId)
infrastructure/ # DB, HTTP-клієнти
В одному з проектів для платформи онлайн-курсів обрали Modular Monolith. Через рік команда з 8 осіб легко виділила сервіс сповіщень в окремий мікросервіс без переписування ядра. Модульність окупилася: вартість доопрацювань знизилася на 40%.
Мікросервіси виправдані, коли різні частини системи потрібно масштабувати незалежно, команди працюють ізольовано на різних доменах, потрібні різні технології (ML-сервіс на Python, API на Go). Також, якщо throughput вимагає горизонтального масштабування окремих компонентів.
Як спроектувати API, щоб не переписувати через рік?
Вибір протоколу API впливає на продуктивність і досвід розробки. tRPC оптимальний для монолітних Next.js/Nuxt додатків: type-safe RPC без кодогенерації. GraphQL — для публічного API з різними клієнтами. REST — для інтеграцій із зовнішніми сервісами. tRPC набирає популярності в TypeScript-додатках, забезпечуючи повну безпеку типів без кодогенерації.
Приклад на tRPC:
// server/routers/users.ts
const usersRouter = router({
getById: publicProcedure
.input(z.object({ id: z.string().uuid() }))
.query(async ({ input }) => {
return db.user.findUnique({ where: { id: input.id } });
}),
create: protectedProcedure
.input(createUserSchema)
.mutation(async ({ input, ctx }) => {
// ctx.user — авторизований користувач
}),
});
// client/pages/users.tsx — типи розділяються автоматично
const { data } = trpc.users.getById.useQuery({ id: userId });
Використання tRPC скорочує кількість багів на стику frontend і backend на 40% завдяки строгій типізації. Запишіться на аудит вашої архітектури, щоб покращити якість API.
Чому CQRS і Repository варто розділяти?
Repository Pattern з Prisma відокремлює логіку доступу від бізнес-правил. Це спрощує тестування та заміну сховища.
// domain/repositories/UserRepository.ts
interface UserRepository {
findById(id: UserId): Promise<User | null>;
save(user: User): Promise<void>;
findByEmail(email: Email): Promise<User | null>;
}
// infrastructure/prisma/PrismaUserRepository.ts
class PrismaUserRepository implements UserRepository {
constructor(private readonly db: PrismaClient) {}
async findById(id: UserId): Promise<User | null> {
const record = await this.db.user.findUnique({
where: { id: id.value }
});
return record ? UserMapper.toDomain(record) : null;
}
}
CQRS (Command Query Responsibility Segregation) розділяє операції зміни та читання. Для складних доменів це дає гнучкість: модель запису може відрізнятися від моделі читання, кожна оптимізована під свої потреби. Martin Fowler: «CQRS підходить тільки для обмежених контекстів з високою складністю». CQRS особливо корисний, коли модель запису та читання сильно відрізняються — наприклад, у системі бронювання квитків операції запису проходять строгі перевірки, а читання оптимізоване для швидкого пошуку.
Як організувати кешування та фонові завдання?
Cache-Aside — найпоширеніший патерн. Дані завантажуються в кеш при першому запиті, а при оновленні інвалідуються. Середній час відповіді з кешем падає з 200ms до 5ms.
Write-Through синхронно оновлює і БД, і кеш, що гарантує узгодженість.
// Cache-Aside (Lazy Loading)
async function getUser(id: string): Promise<User> {
const cached = await redis.get(`user:${id}`);
if (cached) return JSON.parse(cached);
const user = await db.user.findUnique({ where: { id } });
await redis.setex(`user:${id}`, 3600, JSON.stringify(user));
return user;
}
// Write-Through (синхронне оновлення кешу)
async function updateUser(id: string, data: UpdateUserDto): Promise<User> {
const user = await db.user.update({ where: { id }, data });
await redis.setex(`user:${id}`, 3600, JSON.stringify(user));
return user;
}
Для фонових завдань використовуємо BullMQ. Черга з налаштовуваними повторами та пріоритетами.
// BullMQ: типізовані завдання
interface EmailJobData {
to: string;
template: 'welcome' | 'password-reset' | 'invoice';
variables: Record<string, string>;
}
const emailQueue = new Queue<EmailJobData>('emails', { connection: redis });
// Producer (з основного коду)
await emailQueue.add('send', {
to: user.email,
template: 'welcome',
variables: { name: user.name }
}, {
attempts: 3,
backoff: { type: 'exponential', delay: 2000 }
});
// Consumer (окремий воркер)
const worker = new Worker<EmailJobData>('emails', async (job) => {
await emailService.send(job.data);
}, { connection: redis, concurrency: 5 });
Що включає архітектурна консультація?
| Крок | Зміст | Час |
|---|---|---|
| Discovery | Бізнес-вимоги, поточні болі, команда | 2–3 години |
| Рев'ю поточної архітектури | Аналіз коду та схем, якщо проект існує | 1–2 дні |
| Проектування | Схема компонентів, ADR, ризики | 2–3 дні |
| Документація | Architecture Decision Records, C4-діаграми | 1 день |
| Q&A з командою | Розбір неясностей, альтернатив | 2–4 години |
Результат — набір ADR з обґрунтуванням кожного рішення, C4-діаграми та пріоритизований план рефакторингу, якщо проект уже існує.
| Порівняння підходів | Моноліт | Modular Monolith | Мікросервіси |
|---|---|---|---|
| Складність розробки | Низька | Середня | Висока |
| Гнучкість масштабування | Низька | Середня | Висока |
| Overhead на інфраструктуру | Мінімальний | Низький | Високий |
| Ризик технічного боргу | Високий без меж | Низький при правильній модульності | Середній |
Консультація з архітектури нового проекту — 3–5 робочих днів. Аудит існуючої архітектури — 5–10 робочих днів залежно від розміру системи. Отримайте консультацію, щоб закласти правильну архітектурну основу вашого продукту. Зв'яжіться з нами для обговорення деталей.