Как сайт хранит пользователей, пароли и заказы: что происходит за кулисами современных веб-приложений?

Ты зарегистрировался на сайте.

Ввёл логин, придумал пароль, заказал пиццу 🍕, новый ноутбук 💻 или подписку на любимый сервис.

Закрыл вкладку.

Через неделю заходишь снова — и сайт каким-то магическим образом всё помнит.

Но где он это хранит? В текстовом файле? В Excel? В блокноте администратора?

Спойлер: нет. 😄

Давай разберёмся, как сайты на самом деле хранят миллионы пользователей, пароли, товары и заказы.

🗄️ Всё начинается с базы данных

Представь огромную библиотеку.

Только вместо книг — данные.

И лежат они не хаотично, а аккуратно разложены по таблицам.

Например, таблица пользователей может выглядеть так:

А таблица заказов — так:

Обрати внимание: в заказе нет имени пользователя.

Есть только user_id.

Это ссылка на запись в таблице пользователей.

Так данные не дублируются, занимают меньше места и легко связываются между собой.

🤔 А где пароль?

Вот здесь многие новички удивляются.

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

Если база данных утечёт, никто не должен увидеть что-то такое:

123456
qwerty
password
superpassword123

Это был бы настоящий апокалипсис безопасности. 🔥

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

$2b$12$6nWmQKx...

Такая строка называется хэшем.

🔐 Что такое хэш?

Представь мясорубку.

Ты кладёшь туда яблоко 🍎.

На выходе получается пюре.

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

С паролем происходит примерно то же самое:

superpassword123
↓
$2b$12$8Mslf8...

Даже сервер не обязан знать твой настоящий пароль.

Он хранит только результат преобразования.

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

Совпало?

Добро пожаловать. 🎉

🧂 А что такое соль?

Кроме хэширования, к паролю обычно добавляют случайные данные — соль.

Она нужна, чтобы одинаковые пароли разных пользователей превращались в разные хэши.

Например, два человека выбрали пароль:

qwerty123

Без соли их хэши могли бы совпасть.

С солью база получит разные значения, и массово подбирать пароли станет гораздо сложнее.

Современные приложения часто используют алгоритмы bcrypt, Argon2 или scrypt.

🍕 Как хранится заказ?

Когда ты нажимаешь кнопку «Оформить заказ», происходит целая цепочка событий.

1. Frontend отправляет запрос на сервер.

2. Backend получает данные.

3. Сервер проверяет пользователя.

4. Проверяет наличие товара.

5. Считает итоговую сумму.

6. Создаёт запись в базе данных.

7. Возвращает сообщение: «Заказ оформлен».

После этого в таблице появляется новая строка:

Заказ №58391
Пользователь: 15
Статус: Новый
Сумма: 3190 ₽

Именно поэтому потом можно открыть историю заказов, увидеть дату покупки, состав корзины, сумму и текущий статус доставки.

🧾 Почему товары заказа часто хранят отдельно?

Один заказ может содержать несколько товаров.

Поэтому обычно существует не только таблица orders, но и таблица order_items.

Условно структура выглядит так:

orders
- id
- user_id
- total_price
- status
order_items
- order_id
- product_id
- quantity
- price

Это позволяет положить в один заказ клавиатуру, мышку и монитор, не создавая три разных заказа.

💸 Почему цена сохраняется внутри заказа?

Допустим, сегодня клавиатура стоит 6500 ₽, а через месяц магазин повысил цену до 7900 ₽.

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

Пользователь заплатил 6500 ₽, а сайт покажет 7900 ₽. Неловко. 😅

Поэтому цена товара часто копируется в запись заказа в момент покупки.

Так заказ остаётся исторически точным, даже если цена товара позже изменилась.

🧠 Как сайт понимает, что это именно ты?

После успешного входа сайт обычно создаёт специальную сессию или токен.

Проще говоря, сервер выдаёт браузеру цифровой пропуск:

Этот пользователь уже прошёл проверку.

Пока пропуск действует, не нужно вводить пароль при переходе на каждую новую страницу.

Именно поэтому ты можешь открыть профиль, корзину и историю заказов без постоянной повторной авторизации.

🍪 Где хранится этот пропуск?

Часто он сохраняется в cookie — небольшом фрагменте данных, который браузер отправляет сайту вместе с запросами.

Но класть туда пароль нельзя.

Обычно cookie содержит идентификатор сессии или защищённый токен.

А сервер уже по этому идентификатору понимает, какой пользователь отправил запрос.

⚡ Что происходит при миллионах пользователей?

Представь таблицу на 50 миллионов строк.

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

Поэтому базы данных используют специальные структуры — индексы.

Они работают примерно как содержание книги.

Вместо просмотра всех строк база сразу понимает, где находится пользователь с нужным email или заказ с нужным номером.

Но индексы нельзя создавать вообще на всё подряд.

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

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

🔄 Что такое транзакция?

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

Системе нужно:

• создать заказ;

• добавить товары;

• списать остатки со склада;

• сохранить оплату.

А теперь представь, что заказ создался, деньги списались, но сервер упал до добавления товаров.

Получился заказ-призрак. 👻

Чтобы такого не происходило, базы данных используют транзакции.

Идея простая:

Либо выполняются все действия, либо не выполняется ни одно.

Если на одном из этапов произошла ошибка, база отменяет предыдущие изменения.

😅 Почему иногда данные всё-таки теряются?

Обычно не потому, что база данных решила начать новую жизнь.

Чаще причины выглядят так:

• разработчик случайно удалил запись;

• ошибка в SQL-запросе;

• изменения забыли сохранить;

• сервер упал во время операции;

• обновили не ту строку;

• не настроили резервное копирование;

• в коде появилась ошибка синхронизации.

Именно поэтому существуют резервные копии, транзакции, журналы изменений, репликация и другие механизмы защиты.

🛡️ Может ли администратор сайта увидеть пароль?

В правильно сделанной системе — нет.

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

Когда ты нажимаешь «Забыли пароль?», сайт не отправляет его обратно.

Вместо этого он создаёт временную ссылку, по которой можно установить новый пароль.

Если сервис присылает твой старый пароль обычным текстом — это очень тревожный знак. 🚨

🚀 Как научиться работать с данными?

Когда только начинаешь изучать backend, всё это кажется какой-то магией.

Базы данных, SQL, пароли, авторизация, токены, связи между таблицами и транзакции.

Но после нескольких практических проектов отдельные кусочки начинают складываться в единую картину.

Именно поэтому в приложении Кодик упор сделан не только на теорию, но и на практику.

Ты пишешь настоящий код, выполняешь упражнения и постепенно понимаешь, как устроены современные сайты и приложения изнутри.

А ещё у Кодика есть сообщество в Telegram, где выходят полезные посты, короткие разборы, советы и материалы для повторения программирования в удобном формате. 💙

🎯 Итог

Когда пользователь нажимает кнопку «Войти» или «Оформить заказ», за кулисами происходит намного больше, чем кажется.

• Сервер ищет пользователя в базе данных.

• Проверяет хэш пароля.

• Создаёт сессию или токен.

• Загружает связанные данные.

• Создаёт заказ и его товары.

• Сохраняет цену и статус.

• Возвращает результат пользователю.

Всё это происходит за доли секунды.

Никакой магии.

Просто backend, база данных и разработчик, который очень надеется, что не забыл поставить WHERE в SQL-запросе. 😅