Что происходит после нажатия кнопки «отправить» 

Анатомия клика: Что происходит после нажатия кнопки

Пользователь нажимает кнопку «Отправить» и через несколько секунд видит результат.

На экране это выглядит как одно простое действие. С технической точки зрения в этот момент может запускаться целая цепочка процессов:

Причём эта последовательность не является универсальной.

Поэтому полезно разобраться не в конкретной технологии, а в самом принципе.

Предстоит ответить на ключевые вопросы:

• › Что именно происходит после клика?
• › Где формируется запрос?
• › Как браузер находит сервер?
• › Зачем нужен HTTPS?
• › Как запрос попадает в приложение?
• › Почему сервер иногда обращается к базе данных, а иногда отвечает из кэша?
• › Зачем нужны очереди?
• › И почему пользователь может получить ответ, хотя часть работы системы продолжается ещё несколько секунд или минут?

Начнём с простого сценария

Представим обычную корпоративную веб-систему.

Пользователь заполняет форму:

и нажимает:

[ ОТПРАВИТЬ ]

Браузер должен превратить это действие в сетевой запрос.

Но даже эта схема сильно упрощена.

Шаг первый: браузер понимает, что произошло

Пользователь нажимает кнопку. Веб-приложение уже находится в браузере и содержит JavaScript-код, который определяет, что нужно сделать.

Например, при отправке формы приложение может сформировать запрос:

Это уже не «нажатие кнопки».

Это структурированное сообщение серверу:

Важно понимать, что браузер сам по себе не знает бизнес-правил компании.

Он не решает:

• › можно ли создать такую запись;
• › имеет ли пользователь право это сделать;
• › существует ли уже такая компания;
• › можно ли изменить конкретное поле;
• › как сохранить данные;
• › какие дополнительные действия нужно выполнить.

Шаг второй: браузеру нужно найти сервер

Пользователь работает с адресом вроде:

https://portal.example.ru

Но компьютеру для сетевого взаимодействия нужен IP-адрес. Здесь появляется DNS — Domain Name System. DNS переводит доменное имя в сетевой адрес.

Это напоминает телефонную книгу. Человек запоминает имя. Сетевая инфраструктура использует адрес.

Но реальный процесс сложнее.

DNS не передаёт сам запрос приложения

Это важное различие.

DNS отвечает только на вопрос:

Шаг третий: начинается HTTPS

Современные корпоративные системы практически всегда используют HTTPS. В основе HTTPS лежит HTTP поверх защищённого TLS-соединения.

До передачи чувствительных данных клиент и сервер должны договориться о параметрах защищённого соединения и установить криптографический контекст.

После этого содержимое HTTP-запроса передаётся по защищённому каналу. Это означает, что посторонний наблюдатель в сети не должен иметь возможность просто прочитать передаваемые данные в открытом виде.

Шаг четвёртый: запрос попадает не обязательно прямо в приложение

В реальной системе между ними часто находятся дополнительные компоненты.

Зачем всё это?

Потому что современная информационная система должна не только выполнять код.

• › выдерживать нагрузку;
• › контролировать доступ;
• › распределять запросы;
• › обеспечивать отказоустойчивость;
• › управлять трафиком.

Балансировщик распределяет нагрузку

Представим, что приложение работает на пяти экземплярах:

Пользователь не обязан знать, на каком именно сервере будет обработан его запрос. Балансировщик распределяет трафик между доступными экземплярами.

Это позволяет:

• › увеличивать производительность;
• › добавлять новые экземпляры;
• › выводить отдельные серверы из эксплуатации;
• › переживать отказ части инфраструктуры;
• › распределять нагрузку.

Шаг пятый: сервер проверяет, кто отправил запрос

До выполнения бизнес-операции серверу необходимо понять, кто находится по другую сторону соединения.

Если пользователь уже авторизован, браузер может передать соответствующие данные:

• › cookie;
• › session identifier;
• › access token;
• › другие механизмы идентификации.

Сервер извлекает информацию о пользователе и проверяет права.

Это принципиальное разделение.

Шаг шестой: API принимает запрос

Теперь запрос попадает в приложение. API можно рассматривать как формальный интерфейс между клиентом и серверной частью системы.

У каждого endpoint есть определённый контракт. Он может описывать:

• › формат входных данных;
• › обязательные поля;
• › допустимые значения;
• › способ авторизации;
• › формат ответа;
• › возможные ошибки.

Сервер сначала проверяет входные данные

Нельзя просто принять JSON от браузера и записать его в базу. Сервер должен проверить данные.

Но проверка формата — только один уровень.

Может оказаться, что:

• › пользователь не имеет права создавать запись;
• › такая запись уже существует;
• › связанный объект не существует;
• › операция запрещена текущим статусом;
• › значение противоречит бизнес-правилам.

После проверки начинается бизнес-логика

Допустим, пользователь создаёт заказ. Сервер может выполнить цепочку:

Шаг седьмой: сервер обращается к базе данных

Приложение редко хранит постоянные данные непосредственно в оперативной памяти. Ему нужна система хранения. Например:

• › PostgreSQL;
• › Microsoft SQL Server;
• › Oracle Database;
• › MySQL;
• › специализированные NoSQL-системы.

Допустим, сервер должен создать заказ. Он формирует запрос к базе данных:

База выполняет операцию и возвращает результат.

Но даже здесь всё не так просто. Для корпоративных систем критичны:

• › транзакции;
• › ограничения целостности;
• › индексы;
• › блокировки;
• › конкурентный доступ;
• › уровни изоляции;
• › резервное копирование;
• › восстановление;
• › репликация.

Почему приложение не должно просто доверять базе

Часть ограничений действительно может находиться на уровне базы данных. Например, уникальность определённого значения.

Но бизнес-правила обычно требуют более высокого уровня абстракции.

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

А если данные уже есть?

Не каждый запрос требует записи в базу.

Например, пользователь открывает список заказов. Приложение может выполнить:

Backend проверяет права и затем получает данные.

Кэш позволяет не выполнять одну и ту же работу постоянно

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

Шаг восьмой: запрос может уйти в другие сервисы

Современная система редко состоит из одного backend-приложения. Например, при создании заказа основная система может обратиться к:

• › сервису клиентов;
• › сервису расчёта стоимости;
• › сервису складских остатков;
• › сервису платежей;
• › сервису уведомлений;
• › системе управления производством.

И здесь появляется вопрос:

обязательно ли ждать завершения всех операций?

Нет.

Что можно выполнить сразу, а что — потом

Представим, пользователь отправил заказ.

Для ответа ему необходимо:

• › проверить данные;
• › создать заказ;
• › вернуть номер заказа.

Но после этого системе ещё нужно:

• › отправить email;
• › сформировать документ;
• › уведомить склад;
• › записать событие в аналитическую систему;
• › обновить поисковый индекс.

Необязательно заставлять пользователя ждать завершения всех этих операций. Можно разделить процесс.

Зачем нужна очередь

Очередь позволяет отделить момент возникновения события от момента его обработки.

Например:

Событие означает: заказ создан. Один сервис может отправить его в очередь. Другой сервис обработает событие позже.

Это даёт несколько преимуществ:

• › системы меньше зависят друг от друга;
• › можно сглаживать пики нагрузки;
• › временная недоступность потребителя не обязательно блокирует основной процесс;
• › обработку можно повторить;
• › разные потребители могут реагировать на одно событие.

• › что делать с неуспешной обработкой;
• › сколько раз повторять;
• › как избежать дублей;
• › где хранить невалидные сообщения;
• › гарантируется ли порядок;
• › что делать при повторной доставке.

Пользователь может уже получить ответ, хотя система ещё работает

Это один из самых важных моментов.

Допустим, пользователь видит:

Но это не обязательно означает, что абсолютно всё, связанное с заказом, уже завершено.

Поэтому в современных системах нужно различать:

А что происходит, если что-то пошло не так?

Теперь представим другой сценарий. Пользователь нажал «Отправить». Браузер отправил запрос. API его получил. Данные прошли проверку.

Но база данных оказалась временно недоступна.

Система должна корректно обработать эту ситуацию. Пользователь не должен получить абстрактное сообщение:

без дополнительной информации и без понимания, было ли действие выполнено.

В зависимости от архитектуры возможны разные варианты:

• › операция не выполнена;
• › операция выполнена частично;
• › запрос можно безопасно повторить;
• › запрос уже обработан, но ответ потерян;
• › операция поставлена в очередь.

Почему повторный запрос может быть опасен

Представим кнопку:

«Оплатить»

Пользователь нажал её. Запрос ушёл на сервер. Платёжная система обработала операцию. Но ответ от сервера не дошёл до браузера.

Пользователь видит ошибку:

Он нажимает кнопку ещё раз.

Что происходит с ответом

Когда сервер завершил синхронную часть обработки, он формирует HTTP-ответ. Например:

Ответ проходит обратно через сетевую инфраструктуру к браузеру.

Браузер получает ответ и передаёт данные интерфейсу. JavaScript может изменить состояние страницы. Пользователь видит:

Почему ответ иногда приходит мгновенно, а иногда через несколько секунд

Время ответа складывается из множества компонентов.

Если один из этапов начинает работать медленно, пользователь может почувствовать задержку. Причём причина далеко не всегда находится в коде интерфейса.

Медленный экран может быть следствием:

• › медленного SQL-запроса;
• › отсутствующего индекса;
• › перегруженного API;
• › задержки внешнего сервиса;
• › блокировки в базе;
• › сетевой проблемы;
• › нехватки ресурсов;
• › проблем с кэшем.

Как инженеры вообще понимают, где произошла проблема

Для этого используются журналы, метрики и распределённая трассировка. Например, одному пользовательскому запросу присваивается идентификатор:

Этот идентификатор может проходить через несколько компонентов:

Если пользователь говорит:

инженер может посмотреть трассировку и увидеть конкретные задержки:

Современная система — это не один сервер

Для небольшого приложения схема действительно может быть очень простой:

Браузер → Backend → Database

И этого может быть достаточно. Но по мере роста требований архитектура усложняется:

Это не означает, что «хорошая архитектура должна быть сложной». Наоборот.

Один клик не всегда означает один запрос

Современный интерфейс может инициировать сразу несколько сетевых операций.

Например, пользователь открывает карточку заказа. Браузер может одновременно запросить:

На экране пользователь видит одну страницу. Но технически она собирается из нескольких источников.

А иногда браузер вообще не ждёт обычный HTTP-ответ

Для некоторых сценариев нужен поток данных от сервера к клиенту.

Например:

• › онлайн-уведомления;
• › статусы выполнения задач;
• › чаты;
• › мониторинг оборудования;
• › оперативные панели.

Здесь могут использоваться механизмы вроде WebSocket или Server-Sent Events.

Тогда сервер может самостоятельно сообщить браузеру:

Что происходит в корпоративной системе

В enterprise-среде путь запроса обычно ещё сложнее.

Например, сотрудник создаёт заявку. Цепочка может выглядеть так:

Пользователь по-прежнему видит одну кнопку.

Но за ней уже находится распределённая информационная система.

И чем больше компонентов участвует в операции, тем важнее становятся:

• › наблюдаемость;
• › управление ошибками;
• › контроль доступа;
• › трассировка;
• › идемпотентность;
• › управление зависимостями;
• › мониторинг производительности.

Самое важное — не технология, а границы ответственности

Конкретный технологический стек может быть разным. Можно выбрать любой подход к реализации:

• › Можно построить систему на монолите.
• › Можно использовать микросервисы.
• › Можно использовать PostgreSQL, Oracle или другую СУБД.
• › Можно применять Kafka, RabbitMQ или иной механизм очередей.

Но независимо от технологий остаются одни и те же вопросы:

• › кто принимает запрос?
• › кто проверяет права?
• › кто отвечает за бизнес-правила?
• › кто владеет данными?
• › какие операции выполняются синхронно?
• › какие можно вынести в фон?
• › что происходит при ошибке?
• › как система понимает, что запрос уже был обработан?
• › как инженер найдёт проблемный участок?

Полный путь одного запроса

Теперь можно собрать всё в одну сквозную схему:

Конкретная система может выглядеть совершенно иначе.

Где чаще всего скрывается реальная сложность

Инженер должен видеть:

Именно поэтому изменение одного пользовательского действия иногда требует изменений сразу в нескольких компонентах.

Например, добавление нового поля в форму может означать:

• › изменение frontend;
• › изменение API-контракта;
• › изменение бизнес-логики;
• › изменение схемы базы;
• › изменение интеграции;
• › изменение сообщений очереди;
• › изменение аналитики;
• › изменение аудита;
• › обновление документации.

Почему понимание этого пути важно бизнесу

Знание внутренней механики системы нужно не только разработчикам.

Для руководителя проекта или владельца продукта понимание цепочки помогает правильно оценивать изменения.

То же самое касается производительности. Если пользователи жалуются на «медленную систему», вопрос должен звучать не:

а:

От кнопки до результата — это цепочка ответственности

После нажатия «Отправить» не происходит одного большого действия под названием «сервер обработал запрос».

Происходит последовательность.

• › Браузер формирует запрос.
• › DNS помогает найти нужный адрес.
• › HTTPS создаёт защищённый канал.
• › Сетевая инфраструктура доставляет запрос до нужного компонента.
• › Система идентифицирует пользователя и проверяет права.
• › API принимает данные.
• › Backend выполняет бизнес-логику.
• › Приложение обращается к базе, кэшу или другим сервисам.
• › Часть операций может быть вынесена в очередь.
• › Фоновые процессы продолжают работу после того, как пользователь уже получил ответ.
• › А вся цепочка должна быть наблюдаемой, чтобы при проблеме можно было определить, где именно она возникла.

Поэтому современная информационная система — это не просто интерфейс и сервер. Это цепочка взаимосвязанных компонентов, каждый из которых выполняет свою часть работы.

И чем сложнее система, тем важнее не количество используемых технологий, а то, насколько чётко определены границы ответственности, контракты между компонентами, обработка ошибок и путь данных от пользователя до результата.

🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).