Створення високонавантаженого Go-бекенду для мобільного застосунку

Зазначимо: коли сервіс доставки їжі з 80 000 DAU запустив рекламну кампанію, його Node.js-бекенд не витримав пікового навантаження: p99 latency злетів до 800 ms, мобільні клієнти масово отримували таймаути. Ми переписали API на Go — всього за 4 тижні. Результат: p99 впав до 35 ms, витрати на інфраструктуру скоротилися в 3 рази (економія ~$12 000 на місяць).

Горутини та вбудований scheduler дозволяють обслуговувати тисячі з'єднань на одному інстансі без thread pool overhead, що критично для push-heavy застосунків та стрімінгу. Така продуктивність дозволяє скоротити витрати на інфраструктуру на $5 000–$15 000 щомісяця.

Чому Go, а не Node чи Python?

Мобільний клієнт нетерплячий. iOS закриває URLSession через 60 секунд, Android OkHttp за замовчуванням — через 30. Якщо бекенд повільно віддає список новин або користувацький фід, клієнт отримає NSURLErrorTimedOut або SocketTimeoutException, а не дані.

Go вирішує декілька конкретних болів:

• Латентність під навантаженням. net/http обробляє кожен запит в окремій горутині, вартість якої ~2KB пам'яті проти ~1MB у OS thread. При піковому навантаженні (запуск застосунку після маркетингової кампанії, масові пуши) сервер не починає «захлинатися» в черзі потоків.
• Передбачуваний GC. Починаючи з Go 1.14 паузи GC не перевищують 0.5ms у більшості production-сценаріїв — це важливо, коли мобільний клієнт робить polling кожні 15 секунд і чутливий до jitter.
• Компільований бінарник без рантайму. Docker-образ із Go-сервісом важить 15–25 MB. Це пришвидшує cold start у Kubernetes при автоскейлінгу — новий pod стартує за 2–3 секунди замість 20–30 у JVM-застосунків.

Go обробляє запити в 13 разів швидше, ніж Node.js, при навантаженні 500 rps: p99 latency знижується з 450 ms до 35 ms. Висока продуктивність Go робить його ідеальним для мікросервісної архітектури мобільних бекендів.

Архітектура API для мобільного клієнта

Основний стек: Gin або Echo для HTTP-роутингу, sqlx або pgx для роботи з PostgreSQL, go-redis для кешування сесій та rate limiting, zap для структурованих логів. Для аутентифікації мобільного клієнта реалізуємо JWT із refresh-token rotation: access token живе 15 хвилин, refresh — 30 днів. При перевипуску refresh-токена старий інвалідируємо через Redis-set із TTL. Це важливо, тому що мобільні застосунки не можуть використовувати httpOnly cookie так само надійно, як веб — токени зберігаються в Keychain/Keystore.

Приклад реального рішення: застосунок для доставки їжі з 80 000 DAU. API-сервер на Go (Echo v4) обробляв endpoint /orders/active — агрегацію з трьох таблиць PostgreSQL із JOIN'ами. Перша версія на Node.js давала p99 = 450 ms при 500 rps. Після перенесення на Go з connection pool через pgxpool і батч-запитами: p99 = 35 ms при тому ж трафіку. Інфраструктура — той же Kubernetes-кластер, ті ж два пода.

Що входить у повний цикл розробки?

Ми надаємо повний цикл: від аудиту вимог до супроводу в продакшені. На етапі аудиту ми збираємо навантажувальні профілі (rps, p99-latency SLA), список інтеграцій та регуляторні вимоги. Потім проєктуємо схему БД та API-контракт (OpenAPI 3.0). Розробка ведеться з покриттям ключових сценаріїв тестами (testing + testify). Після тестування — деплой через Docker + Kubernetes, CI через GitHub Actions або GitLab CI.

Зазначимо: Що ви отримуєте:

• Працюючий API з документацією (Swagger/OpenAPI)
• Інтеграцію з push-сервісами (FCM, APNs) та платіжними системами
• Систему моніторингу (Prometheus + Grafana) та алертингу
• Вихідний код у приватному репозиторії
• Навчання вашої команди основам підтримки
• Гарантію безперебійної роботи на SLA

Процес роботи

1. Аудит вимог — збір навантажувальних профілів, інтеграцій та регуляторних вимог.
2. Проєктування — схема БД та API-контракт (OpenAPI 3.0).
3. Розробка — реалізація з тестами (testing + testify).
4. Тестування — навантажувальне тестування та перевірка SLA.
5. Деплой — Docker + Kubernetes, CI через GitHub Actions або GitLab CI.

Терміни: від 3–5 тижнів для простого API (10–15 методів, одна БД) до 8–14 тижнів для сервісу з ріалтаймом (WebSocket/SSE), кількома інтеграціями та аналітикою. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту.

Типові помилки на Go-бекенді для мобайлу

• Відсутність rate limiting на рівні IP + user — мобільний клієнт при поганому з'єднанні робить retry у циклі, без обмежень це вбиває БД.
• database/sql без явного SetMaxOpenConns — за замовчуванням ліміт з'єднань необмежений, при піку отримуєте connection refused від PostgreSQL.
• Синхронне надсилання push у HTTP-handler — FCM/APNs можуть відповідати 200–500ms, це блокує горутину і збільшує latency; пуши — тільки через чергу (Redis Streams або RabbitMQ).
• Ігнорування context.Context скасування — при дисконекті мобільного клієнта запит до БД повинен скасовуватися, інакше накопичуються завислі транзакції.

Порівняння Go vs Node.js vs Python

Гарантія якості

Наш досвід — 10+ років у розробці мобільних бекендів та понад 50 успішних проєктів. Ми гарантуємо дотримання термінів та SLA 99.9% uptime. Всі проєкти проходять code review та навантажувальне тестування. Отримайте консультацію — оцінимо ваш проєкт безкоштовно. Замовте розробку Go-бекенду вже сьогодні.