Системный дизайн инфраструктуры

Держите каждый слой избыточным: несколько stateless-инстансов за балансировщиком, который health-проверяет цели и шлёт трафик только на здоровые, а session и загруженные файлы вынесены в общее хранилище, чтобы любой инстанс обслуживал любой запрос. Сделайте БД primary с репликами и автоматическим failover, разгружая чтения на реплики. Добавьте graceful degradation, чтобы падающий слой сбрасывал нагрузку, а не каскадил отказ.

Кешируйте слоями: CDN/edge-кеш для статики и кешируемых ответов через HTTP cache-заголовки, кеш приложения вроде Redis для горячих данных и результатов запросов и read-реплики БД. Задавайте TTL по терпимости данных к устареванию, инвалидируйте или обновляйте записи при изменении источника и защищайте горячие ключи от stampede при протухании. Компромисс — дешёвая отдача слегка устаревших данных против сложности держать каждый слой корректным.

Поставьте на каждый хост агент сбора, шлющий в буферизованный транспорт (очередь или брокер), чтобы замедление ниже по потоку не теряло логи и не блокировало приложение. Складывайте их в индексированное хранилище, но разбейте хранение на уровни — горячее для свежих данных, дешёвый архив для старых, шум отбрасывать, — ведь индексировать всё разоряет бюджет. Ограничьте high-cardinality поля и раскатайте агент через config management, чтобы все 500 хостов были едины.

Задайте RPO (допустимую потерю данных) и RTO (допустимый простой) из терпимости бизнеса, затем подберите механизмы: частота и тип бэкапов задают RPO; скорость restore и failover задаёт RTO. Снимайте бэкапы с этой частотой, храните их изолированно от основного, чтобы один отказ не уничтожил оба, и — критично — тестируйте восстановление, ведь непроверенный бэкап — не бэкап. Держите отрепетированный runbook failover, чтобы восстановление не импровизировали.

Используйте все три столпа по их сильной стороне: метрики — для дешёвых агрегатных трендов и алертов, логи — для контекста по событию, трейсы — чтобы вести запрос через переходы между сервисами. Инструментируйте каждый сервис одинаково с проброшенными trace ID. Алертите на пользовательские симптомы — burn SLO и сигналы RED/USE, а не на каждую причину, — остальное держите для отладки. Ограничьте кардинальность лейблов, чтобы time-series БД не взорвалась.

Держите каждый секрет в центральном хранилище как единый источник истины; каждый сервис аутентифицируется собой и получает секреты в рантайме, а не запечёнными в образ. Ограничьте доступ по сервису по least privilege, чтобы одна компрометация не читала всё, и предпочитайте короткоживущие динамические доступы с авто-истечением, что ужимает радиус поражения и делает ротацию рутиной, а не передеплоем. Держите открытый текст вне кода, логов и CI.

Масштабируйте по сигналу ближе к реальной нагрузке — запросы или глубина очереди, а не только CPU. Реактивный автоскейлинг отстаёт от всплеска на время загрузки и прогрева, поэтому держите тёплый буфер headroom и предмасштабируйте по расписанию или прогнозу. Задайте min/max и защиту от scale-in, чтобы не флаппило. Компромисс — стоимость против headroom: работа у 100% утилизации экономит деньги, но не оставляет запаса под всплески.

Держите счётчики в быстром общем хранилище вроде Redis, которое все stateless-инстансы обновляют атомарно, ведь счётчик в памяти на инстанс лимитирует только этот инстанс, а не глобальный ключ. Обеспечьте средний темп, позволяя контролируемые всплески (token bucket). Ограничьте задержку проверки, а при недоступности хранилища осознанно выбирайте fail-open или fail-closed. Более строгая глобальная точность стоит общего обращения на каждом запросе.

Применяйте expand/contract: добавьте колонку аддитивно и заполните её, выкатите код, который пишет в обе и читает новую с откатом к старой, затем удалите старую колонку только когда весь флот на новом коде. Каждый шаг остаётся обратно совместимым, поэтому старая и новая версии делят одну схему во время rolling-выката, сливающего и заменяющего инстансы. Один разрушительный ALTER сломал бы ещё работающий старый код и вызвал простой.