Розробка мікросервісної архітектури бекенду мобільної додатка
Перехід до мікросервісів виправданий не тоді, коли «так модно», а коли моноліт починає створювати конкретні операційні проблеми: команда з 15+ розробників конфліктує в одній кодовій базі, релізний цикл сповільнився до двох тижнів через координацію між відділами, або одна «гаряча» фіча (стрімінг, обробка платежів) вимагає окремого масштабування, а не тягнути за собою весь моноліт.
Де мікросервіси створюють більше проблем, ніж вирішують
Почнемо з антипаттернів, бо саме туди йде більшість бюджетів.
Distributed monolith. Розбили моноліт на 15 сервісів, але кожен запит мобільного клієнта синхронно чекає ланцюг викликів: API Gateway → UserService → OrderService → ProductService → PaymentService. Один сервіс лагує — весь запит висить. Це не мікросервісна архітектура, це моноліт через HTTP з додатковим latency overhead. Ознака: сервіси не можуть працювати незалежно, деплой одного вимагає координації з іншими.
Grapevine data consistency. OrderService синхронно викликає InventoryService, отримує 200 OK, але між перевіркою залишків та списанням інший запит встиг занять останній товар. Race condition на рівні розподіленої системи. Рішення — Saga pattern: або choreography (події через Kafka/RabbitMQ), або orchestration (Temporal, Apache Camel).
Overhead на малих командах. Три розробники, п'ять сервісів — кожен деплой вимагає оновлення п'яти Docker-образів, п'яти Helm-чартів, п'яти наборів змінних середовища. Velocity падає, помилки конфігурації ростуть. Для команди до 8 осіб модульний моноліт (Modular Monolith) або monolith-first з подальшою декомпозицією — чесніше.
Як будуємо мікросервісну архітектуру для мобільної додатка
Декомпозиція по доменам (Domain-Driven Design)
Bounded Context — основний принцип: кожен сервіс володіє своїми даними та не читає чужу БД напрямую. Типова декомпозиція для e-commerce мобільної додатка:
| Сервіс | Відповідальність | БД |
|---|---|---|
| user-service | Реєстрація, профіль, автентифікація | PostgreSQL |
| catalog-service | Товари, категорії, пошук | PostgreSQL + Elasticsearch |
| order-service | Замовлення, статуси, історія | PostgreSQL |
| payment-service | Платіжні методи, транзакції | PostgreSQL |
| notification-service | Push, email, SMS | Redis + PostgreSQL |
| media-service | Завантаження та обробка медіа | S3 + PostgreSQL |
API Gateway — єдина точка входу для мобільного клієнта
Мобільний клієнт ніколи не знає топологію сервісів. Один хост, один TLS-сертифікат. Gateway бере на себе: аутентифікацію JWT (не дублюємо в кожному сервісі), rate limiting, маршрутизацію по версіях API, трансформацію запитів.
Технології: Kong (production-proven, плагіни для auth/rate limit/logging), AWS API Gateway якщо інфраструктура в AWS, Traefik для Kubernetes-native рішення. Для команд, які хочуть кастомну логіку — custom Gateway на Go (BFF — Backend for Frontend), особливо якщо мобільний клієнт потребує агрегації даних з кількох сервісів в одну відповідь.
Асинхронна комунікація
Синхронні виклики між сервісами — тільки там, де результат потрібен негайно (перевірка ліміту перед платежем). Все решта — через message broker.
Apache Kafka для високонавантажених сценаріїв: event sourcing, аудит-лог, стрімінг метрик. Топік order.created — підписані notification-service (відправить push), analytics-service (оновить метрики), loyalty-service (нараховує бали). Кожен незалежно, без coupling.
RabbitMQ для task queue: трансджодування відео, генерація PDF, відправка email. Простіше в операційному плані, достатньо для більшості мобільних додатків.
Кейс: платформа для стрімінгу фітнес-контенту, 200 000 MAU. Вихідний моноліт на Node.js почав давати timeout на /api/workouts/start — там синхронно викликалися: запис у лог, оновлення прогресу, інкремент лічильника переглядів, перевірка ачівок. Декомпозиція: workout-service публікує подію workout.started у Kafka, інші сервіси обробляють асинхронно. Latency endpoint: з 800ms до 40ms.
Service Mesh та observability
У мікросервісному середовищі без observability ви сліпі. Обов'язковий мінімум:
- Distributed tracing — Jaeger або Zipkin з OpenTelemetry SDK у кожному сервісі. Коли мобільний клієнт скаржиться на повільну відповідь, trace показує який сервіс винний
-
Centralized logging — ELK Stack (Elasticsearch + Logstash + Kibana) або Loki + Grafana. Correlation ID пробрасується через всі сервіси у заголовках (
X-Trace-ID) - Service mesh — Istio або Linkerd для mTLS між сервісами, circuit breaker, retry, timeout на рівні інфраструктури, без коду
Circuit Breaker захисту мобільного клієнта
Якщо payment-service деградує, order-service має швидко повернути fallback, а не чекати таймаут 30 секунд. Resilience4j (Java), Polly (.NET), go-circuitbreaker — circuit breaker розмикається після N послідовних помилок, швидко повертає 503, через 30 секунд пробує знову. Мобільний клієнт отримує відповідь за 100ms, а не таймаут.
Процес впровадження
Міграція монолітів у мікросервіси — не «переписуємо все разом». Паттерн Strangler Fig: новий функціонал — окремий сервіс, старий — поступово вирізується з монолітом. Починаємо з найменш пов'язаних доменів (звичайно сповіщення, медіа, аналітика).
Терміни: Проектування архітектури + базова інфраструктура (Gateway, брокер, моніторинг) — 4–6 тижнів. Повна декомпозиція продуктового монолітом у 5–8 сервісів з CI/CD — 16–24 тижні.