Топ-5 архитектурных "костылей", которые мы постоянно находим на сайтах отечественных компаний

За годы работы лаборатория ОЗАТ провела десятки аудитов IT-инфраструктуры для казахстанских компаний — от локальных интернет-магазинов до крупных логистических порталов и финтех-стартапов. И каждый раз, заглядывая "под капот" очередного проекта, мы с вероятностью 80% находим одни и те же архитектурные ошибки. Это не просто "некрасивый код". Это бомбы замедленного действия, которые приводят к падению серверов в Черную пятницу, утечкам персональных данных и огромным счетам за хостинг.

Чаще всего эти проблемы возникают из-за того, что бизнес требует "сделать быстро", а разработчики выбирают путь наименьшего сопротивления, жертвуя масштабируемостью. В этой статье мы разберем топ-5 самых частых и опасных архитектурных "костылей", которые мы встречаем на отечественном рынке, и расскажем, как от них избавиться.

1. "Все в одном флаконе", или Монолитная база данных для всего

Классическая картина: компания разрабатывает интернет-магазин. Вся информация — товары, заказы, профили пользователей, логи действий, аналитика и сессии — хранится в одной гигантской таблице или базе данных PostgreSQL/MySQL.

В чем опасность? Когда стартует маркетинговая акция, на сайт приходит в 10 раз больше пользователей. Они начинают активно искать товары. Эти поисковые запросы (SELECT) перегружают базу данных. В результате процессор базы забивается на 100%, и она перестает отвечать. Пользователи не могут не только искать, но и оформлять заказы (INSERT), а администраторы не могут зайти в панель управления. Сайт "лежит", бизнес теряет деньги.

Как правильно: Разделяйте базы данных по бизнес-доменам (Microservices Database Pattern) и используйте правильные инструменты. Для поиска товаров нужен Elasticsearch или Meilisearch. Для хранения сессий и корзин — Redis. Для логов и аналитики — ClickHouse или BigQuery. Основная реляционная база должна заниматься только транзакциями (заказами и оплатами). В Google Cloud это легко реализуется через управляемые сервисы, такие как Cloud SQL, Memorystore (Redis) и BigQuery, которые масштабируются независимо друг от друга.

2. Синхронная обработка тяжелых задач

Вы загружаете Excel-прайс на 100 000 позиций в админку. Нажимаете кнопку "Загрузить". И... страница зависает на 15 минут. Вы сидите и смотрите на крутящийся лоадер, молясь, чтобы интернет не моргнул, иначе придется начинать всё сначала.

В чем опасность? Сервер пытается обработать огромный файл в том же процессе, который отвечает за выдачу веб-страниц. Если несколько менеджеров одновременно загрузят тяжелые отчеты, рабочие процессы веб-сервера (worker pool) будут исчерпаны. Сайт перестанет открываться у всех остальных пользователей. Кроме того, при сбое нет механизма повторных попыток (retries) — процесс просто умирает.

Как правильно: Использовать асинхронные очереди (Message Queues). При загрузке файла сервер должен просто сохранить его в объектное хранилище (например, Google Cloud Storage), поставить задачу в очередь (RabbitMQ, Kafka или Google Cloud Pub/Sub) и сразу ответить пользователю: "Файл принят в обработку". А в фоне специальные "воркеры" неспеша и надежно распарсят этот файл. Пользователю останется только прислать уведомление по завершении. Это базовый паттерн Event-Driven Architecture.

3. Жестко зашитые ключи и пароли (Hardcoded Secrets)

Это самый пугающий пункт. Мы регулярно находим в исходном коде проектов ключи от платежных шлюзов, пароли от баз данных и токены API. Иногда этот код даже лежит в публичных репозиториях на GitHub.

В чем опасность? Если злоумышленник получит доступ к исходному коду (например, через уязвимость в библиотеке или уволенного сотрудника), он автоматически получит доступ ко всей вашей инфраструктуре и деньгам на счетах.

Как правильно: Использовать специализированные менеджеры секретов. В инфраструктуре Google Cloud для этого есть Secret Manager. Приложение при старте должно запрашивать пароли из защищенного хранилища. Сами разработчики вообще не должны знать продакшн-пароли — доступ к Secret Manager регулируется строгими политиками IAM (Identity and Access Management).

4. Хранение загруженных файлов локально на сервере

Пользователи загружают аватарки или документы, и сервер сохраняет их в папку /var/www/site/uploads прямо на жесткий диск виртуальной машины.

В чем опасность? Во-первых, диск не резиновый. Рано или поздно место закончится, и сайт упадет с ошибкой No space left on device. Во-вторых, это делает невозможным горизонтальное масштабирование. Если из-за нагрузки вы запустите второй сервер, пользователи, попавшие на него, не увидят картинки, загруженные на первый сервер. При удалении виртуальной машины (например, при сбое) вы потеряете все пользовательские файлы.

Как правильно: Любой современный сайт должен быть Stateless (без сохранения состояния на самом сервере). Все загружаемые файлы должны отправляться в объектное хранилище (S3-совместимое или Google Cloud Storage). Оно имеет бесконечный объем, стоит копейки и может раздавать файлы через глобальную CDN с невероятной скоростью, снимая нагрузку с вашего основного сервера.

5. Отсутствие мониторинга и "слепой" деплой

Релиз новой функции выглядит так: разработчик подключается по SSH к серверу и выполняет команду git pull. Если что-то ломается, узнают об этом только тогда, когда звонят разъяренные клиенты. Никто не знает, сколько памяти потребляет приложение и какие запросы к базе данных выполняются медленнее всего.

В чем опасность? Бизнес несет репутационные и финансовые потери. Процесс исправления ошибок (hotfix) занимает часы, потому что разработчики ищут проблему в логах, разбросанных по разным файлам.

Как правильно: Внедрение базовых практик CI/CD и Observability. Деплой должен быть автоматизирован (через GitLab CI или GitHub Actions) и выполняться без даунтайма (Blue-Green или Canary deployment). Все логи и метрики должны централизованно собираться. Например, Google Cloud Operations Suite (бывший Stackdriver) позволяет в реальном времени видеть графики нагрузки, трейсинг запросов и получать алерты в Telegram, если количество 500-х ошибок превысит норму. Инженеры должны узнавать о проблемах за секунды, а не от клиентов.