Как мы превратили проблемный код в масштабируемую платформу: технический разбор проекта Blogerito
В 2024 году к нам обратился основатель Blogerito — платформы для бартера между блогерами и маркетплейсами. Проект уже работал, но с
критическими проблемами:
Команда GemsTeam провела аудит и за 3 месяца превратила систему в отказоустойчивую платформу. Вот как мы это сделали.
критическими проблемами:
- Сервер падал при 30+ пользователях
- Финансовые операции терялись
- Чат «лагал» на простейших запросах
Команда GemsTeam провела аудит и за 3 месяца превратила систему в отказоустойчивую платформу. Вот как мы это сделали.
Команда разработки
Gems.team
Архитектура: от спагетти-кода к DDD
Проблема:
Исходный код напоминал свалку
Решение:
Разделили код на микросервисы:
Исходный код напоминал свалку
- Бизнес-логика в шаблонах Django
- Конфигурационные файлы на 1000+ строк
- Нулевая модульность
Решение:
Разделили код на микросервисы:
# Было
def process_order(request):
# 200 строк логики + рендеринг HTML
# Стало
class OrderService:
@transaction.atomic
def create(self, data): ...
def process_order(request):
# 200 строк логики + рендеринг HTML
# Стало
class OrderService:
@transaction.atomic
def create(self, data): ...
- Внедрили Event-Driven Architecture для чата и платежей.
Результат:
Значительное ускорение внедрение новых функций, упрощена поддержка кода.
DevOps: убиваем Apache
Проблема:
Что сделали:
- Apache работал в режиме prefork (1 поток = 1 процесс)
- DEBUG=True в продакшене (утечки памяти)
Что сделали:
- Перешли на Nginx + Gunicorn (20 воркеров)
- Настроили Kubernetes для автоскейлинга
- Добавили Prometheus для мониторинга:
# Пример метрики
- name: db_queries
query: 'rate(pg_stat_activity_count[5m])'
- name: db_queries
query: 'rate(pg_stat_activity_count[5m])'
Итог: Сервер теперь выдерживает 10 000+ одновременных сессий.
Чат: WebSockets vs API
Проблема:
Решение:
- Каждое сообщение — новый HTTP-запрос
- SELECT * FROM messages WHERE chat_id = ... (500+ ms)
Решение:
- Внедрили Django Channels + Redis Pub/Sub
- Оптимизировали запросы:
# Было
Messages.objects.filter(chat=chat_id)
# Стало
Messages.objects.only('text', 'sender').filter(chat=chat_id).select_related('sender')
Messages.objects.filter(chat=chat_id)
# Стало
Messages.objects.only('text', 'sender').filter(chat=chat_id).select_related('sender')
Итог: Сервер теперь выдерживает 10 000+ одновременных сессий.
Postgres: контейнеры и пулы
Проблема:
Исправление:
Эффект: Скорость отчетов выросла в 5 раз.
- БД «на железе» с 20 соединениями
- max_connections = 100 (но сервер падал при 30)
Исправление:
- Запустили Postgres в Docker + PgBouncer
- Настроили индексы для тяжелых запросов:
- CREATE INDEX CONCURRENTLY ON messages (chat_id, created_at);
Эффект: Скорость отчетов выросла в 5 раз.
Безопасность: от секретов в коде до Vault
Что было:
Что сделали:
- DATABASE_PASSWORD = "qwerty123" в settings
- Git-история с доступом к prod
Что сделали:
- Внедрили HashiCorp Vault для секретов
- Настроили GitLab CI/CD с проверками:
# .gitlab-ci.yml
secrets:
VAULT_ADDR: "https://vault.example.com"
secrets:
VAULT_ADDR: "https://vault.example.com"
Итог: Zero-day уязвимостей с момента внедрения.
Заключение
За 3 месяца мы:
- Увеличили производительность в 3 раза
- Снизили затраты на инфраструктуру на 60%
- Обеспечили 99.9% uptime
ООО «ДЖЕМСТИМ»
ИНН 7716980900 ОГРН 1237700264340
ИНН 7716980900 ОГРН 1237700264340
