Портал государственных услуг – это витрина, за которой стоят десятки ведомственных систем. Гражданин нажимает «Подать заявление», а в этот момент портал дёргает регистры ФМС, ПФР, ФНС, базы регионов. Нагрузка распределена неравномерно: подача деклараций к концу апреля, запись в первый класс в день старта приёма, проверка штрафов после рассылки постановлений. Эти пики ломают системы, спроектированные «на средний RPS». Устойчивость к таким пикам закладывается ещё на этапе заказной разработки бизнес-систем, и ниже разобраны ключевые решения.

Считайте пики, а не среднюю нагрузку

Средняя нагрузка обманывает. Запись в детский сад открывается в 08:00 и за первые десять минут приходит больше запросов, чем за остальные сутки. Проектируйте под пик с запасом 3–5×, измеряйте латентность в перцентилях (p95, p99), а не в среднем. Один медленный запрос к ведомству на хвосте распределения держит поток и пользователя, и сессию на портале.

Ключевое решение – развязать фронт портала и ведомственные вызовы. Портал должен отдавать форму, принимать заявление и ставить его в очередь, не дожидаясь синхронного ответа от регистра. Дальше работает асинхронный обмен через СМЭВ и межведомственное взаимодействие: заявление уходит в ведомство, статус приходит позже, гражданин видит его в личном кабинете. Синхронно отвечают только быстрые операции – валидация, проверка дублей, авторизация через ЕСИА.

Очереди, кэш и деградация вместо отказа

Высокая нагрузка убивает не вычисления, а ожидание ответов от медленных смежников. Поэтому между порталом и ведомствами ставьте брокер сообщений и сервисную шину. Точечные синхронные интеграции «портал – каждая система» не выдерживают: при отказе одного регистра падает вся цепочка. Почему шина, а не россыпь коннекторов, мы разбирали в материале про ESB против point-to-point – для портала с десятками поставщиков данных аргумент тот же.

Кэшируйте справочники агрессивно: ОКАТО, перечни услуг, реестры органов власти меняются редко, а запрашиваются постоянно. Вынесите статику и формы на отдельный слой, чтобы динамика не делила с ними ресурсы. И заложите управляемую деградацию: если регистр недоступен, портал принимает заявление в очередь и показывает «отправлено, ожидает обработки», а не «ошибка 500». Для гражданина это разница между доверием и жалобой.

Не недооценивайте интеграцию со старым

Большинство ведомственных регистров – это системы десятилетней давности, не рассчитанные на веб-нагрузку. Нельзя просто открыть к ним прямой доступ из портала: они лягут на первой сотне одновременных запросов. Перед ними нужен буферный слой – адаптер, который дросселирует поток, кэширует ответы и переводит протоколы. Подходы к такой работе со старыми системами мы описывали в заметке про миграцию legacy. На госуслугах чаще не мигрируют, а оборачивают: регистр остаётся на месте, а адаптер защищает его от пиков портала.

Вывод

Высоконагруженный портал госуслуг – это не мощный сервер, а правильная архитектура развязки. Считайте пики, а не среднее. Делайте обмен с ведомствами асинхронным через шину и очереди. Кэшируйте справочники, проектируйте деградацию вместо отказа и закрывайте старые регистры буферным слоем. Тогда система переживёт и старт записи в школу, и дедлайн по декларациям – без падений и без потерянных заявлений.