Системный дизайн: кеширование, прокси и хранилища

Зачем читать эту статью?

Системный дизайн — ключевой навык для любого разработчика, который хочет строить масштабируемые и надёжные приложения. В этой части мы разберём кеширование, прокси, балансировщики нагрузки и хранилища — темы, без которых не обходится ни одно собеседование. Вы узнаете, как ускорить ответы сервера в 10 раз, чем отличается SQL от NoSQL и как CAP-теорема влияет на выбор базы данных. Готовы прокачать свой системный дизайн? Поехали!

Кеширование: ускоряем доступ к данным

Что такое кеширование?

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

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

Уровни кеширования

• Клиентская сторона: браузеры кешируют изображения и скрипты локально.
• CDN: edge-серверы кешируют контент рядом с пользователем.
• Серверная сторона: приложение кеширует часто запрашиваемые данные в памяти (Redis, Memcached).

Ключевые термины

• Cache Hit: данные найдены в кеше ✅
• Cache Miss: данных нет — запрос уходит в первичный источник ❌
• Cache Hit Ratio: процент запросов, обслуженных из кеша. Чем выше, тем лучше.

Стратегии записи

• Write-through: запись одновременно в кеш и БД. Консистентно, но медленнее.
• Write-back (Write-behind): сначала в кеш, БД обновляется асинхронно. Быстро, но риск потери данных при сбое кеша.
• Write-around: запись напрямую в БД, кеш обходится. Подходит для данных, которые редко перечитываются.

Политики вытеснения

Когда кеш заполнен, нужно удалить старые данные:

• LRU (Least Recently Used): удаляется элемент, к которому дольше всего не обращались.
• LFU (Least Frequently Used): удаляется элемент с наименьшей частотой обращений.
• FIFO (First In, First Out): удаляется самый старый элемент.

Популярные серверные инструменты: Redis и Memcached. Redis предпочтительнее, так как поддерживает богатые структуры данных, персистентность и репликацию.

Инвалидация кеша — одна из сложнейших проблем распределённых систем. Два подхода: установка TTL (Time-to-Live) или явная инвалидация при изменении данных.

Content Delivery Networks (CDN)

CDN — географически распределённая сеть серверов, которая кеширует статический контент (изображения, видео, CSS, JS) и доставляет его с ближайшего к пользователю узла, снижая задержку.

Две модели:

• Push CDN: контент проактивно отправляется на edge-узлы до запроса. Лучше для редко меняющегося контента.
• Pull CDN: контент загружается с origin-сервера при первом запросе и кешируется. Подходит для крупных сайтов с множеством ресурсов.

Прокси и балансировщики нагрузки

Прокси — промежуточный сервер между клиентом и бэкендом. Два типа:

• Forward Proxy: стоит перед клиентом — сервер не знает, кто настоящий клиент. Примеры: VPN, корпоративные файрволы.
• Reverse Proxy: стоит перед сервером — клиент не знает, какой бэкенд обрабатывает запрос. Пример: Nginx. В системном дизайне под «прокси» обычно подразумевают reverse proxy.

Балансировщик нагрузки — разновидность reverse proxy, распределяющая входящий трафик между несколькими серверами. Стратегии:

• Round Robin: запросы отправляются по кругу.
• Least Connections: трафик идёт на сервер с наименьшим числом активных соединений.
• IP Hashing: IP-адрес клиента хэшируется для постоянного направления на один сервер (полезно для сессий).

Обычный vs. Consistent Hashing

При обычном хэшировании (hash(key) % N) добавление или удаление сервера приводит к перераспределению почти всех ключей — полная перетасовка. Consistent Hashing решает эту проблему, размещая серверы и запросы на виртуальном кольце. При изменении состава серверов перераспределяются только ключи, привязанные к изменившемуся узлу. Это минимизирует disruption и широко используется в распределённых кешах и базах данных.

Reverse proxy также обеспечивает SSL-терминацию, безопасность (скрытие внутренней структуры), кеширование, логирование и сжатие ответов.

Хранилища: SQL, NoSQL и масштабирование

SQL vs. NoSQL

Один из самых частых вопросов на собеседованиях: «Какую базу данных вы выберете и почему?»

SQL (реляционные базы данных) хранят данные в структурированных таблицах с предопределённой схемой. Примеры: PostgreSQL, MySQL. Обычно используют B+ деревья для индексации, что позволяет эффективно выполнять range-запросы. SQL следует ACID:

• Atomic: транзакция выполняется полностью или не выполняется вовсе.
• Consistent: транзакция переводит БД из одного валидного состояния в другое.
• Isolated: параллельные транзакции выполняются независимо.
• Durable: после коммита данные сохраняются даже при сбое.

NoSQL жертвуют структурой и строгой консистентностью ради гибкости и горизонтального масштабирования. Вместо ACID используют BASE:

• Basically Available: система всегда возвращает ответ, даже если он устаревший.
• Soft State: состояние может меняться со временем без внешних воздействий.
• Eventual Consistency: со временем все реплики придут к согласованному состоянию.

Объектное хранилище

Предназначено для больших неструктурированных файлов (изображения, видео, бэкапы). Amazon S3 — самый популярный пример. Нет иерархии папок — плоская структура объектов с уникальным ключом и метаданными. Ключевые свойства: высокая надёжность, экономичность при больших объёмах, доступ через HTTP API. Не подходит для часто обновляемых записей или низколатентных lookup-запросов.

Репликация

Репликация — копирование данных на несколько экземпляров БД для повышения доступности, производительности чтения и отказоустойчивости.

• Синхронная: primary ждёт подтверждения от реплик перед ответом. Всегда консистентно, но медленнее.
• Асинхронная: primary отвечает сразу, реплики догоняют позже. Быстрее, но есть окно неконсистентности.

Архитектуры:

• Leader-Follower: один primary обрабатывает запись, реплики — чтение. Просто, но primary — единая точка отказа для записи.
• Leader-Leader (Multi-Primary): несколько узлов принимают запись. Более устойчиво, но сложнее разрешение конфликтов.

CAP-теорема и консистентность

CAP-теорема утверждает, что распределённое хранилище может гарантировать только два из трёх свойств одновременно:

• Consistency: каждый read возвращает последнюю запись или ошибку.
• Availability: каждый запрос получает ответ (не обязательно свежие данные).
• Partition Tolerance: система продолжает работу при потере связи между узлами.

Поскольку сетевые разделы неизбежны, P требуется всегда — выбор между C и A:

• CP-системы (например, HBase): отказывают в запросах во время раздела, чтобы не возвращать устаревшие данные.
• AP-системы (например, Cassandra, DynamoDB): остаются доступными, но могут вернуть устаревшие данные.

Это связано с выбором между strong consistency (гарантирует свежие данные, но выше задержка) и eventual consistency (допускает кратковременные несоответствия ради производительности).

Шардирование

Шардирование — горизонтальное партиционирование, при котором данные распределяются по нескольким базам (шардам), каждая из которых содержит часть данных. Это способ масштабирования БД за пределы одной машины.

Стратегии:

• Range-based: деление по диапазону значений (например, user_id 0–25M на шард A). Просто, но может привести к неравномерной нагрузке (горячие шарды).
• Hash-based: хэш ключа шарда равномерно распределяет данные, но усложняет range-запросы.
• Directory-based: таблица соответствий записей шардам. Гибко, но таблица становится узким местом.

Главный недостаток — сложность и дороговизна cross-shard запросов. Ребалансировка при добавлении/удалении шардов тоже нетривиальна — здесь снова помогает consistent hashing.

Что делать прямо сейчас

1. Настройте Redis для кеширования в вашем pet-проекте. Измерьте, как изменилось время ответа.
2. Сравните SQL (PostgreSQL) и NoSQL (MongoDB) на простом примере: создайте схему для блога и объясните выбор.
3. Симулируйте CAP-теорему: возьмите две ноды с Cassandra (AP) и PostgreSQL (CP) и проверьте поведение при разрыве сети.
4. Реализуйте consistent hashing на Python: напишите класс с методами добавления/удаления узлов и получения узла по ключу.

Эти упражнения закрепят теорию и подготовят вас к вопросам на собеседованиях. Удачи!