Словарь веб-разработчика

Race condition (состояние гонки) — ошибка, возникающая когда результат зависит от порядка выполнения параллельных операций. Классический пример: два запроса одновременно читают баланс ($100), оба снимают $80, оба записывают $20 — но должно быть -$60.В БДРешается транзакциями с подходящим уровнем изоляции или SELECT ... FOR UPDATE — блокировка строки до конца транзакции.В кэшеАтомарные операции Redis (INCR, SETNX, Lua-скрипты) предотвращают гонку на уровне кэша.Оптимистичная vs пессимистичная блокировкаОптимистичная — при записи проверяем, изменились ли данные с момента чтения (version number / CAS). Нет блокировок, но возможен retryПессимистичная — блокируем ресурс при чтении, чтобы никто не изменил. Без retry, но снижает параллелизм

RAG — архитектурный паттерн, дополняющий LLM актуальными данными из внешнего хранилища. Вместо того чтобы «запоминать» все факты в параметрах модели, нужная информация находится во время запроса и передаётся в контекст.Схема RAGПользователь задаёт вопросСистема векторным поиском находит релевантные документыДокументы добавляются в промпт как контекстLLM генерирует ответ на основе контекстаПреимуществаАктуальные данные без переобучения моделиКонтроль источников — ответы основаны на конкретных документахСнижение галлюцинаций для фактических вопросовКогда нуженQ&A по корпоративной документации, поиск в большой базе знаний, чатбот, отвечающий на вопросы по продукту.

Rate limiting — ограничение количества запросов от одного клиента (IP, токен, user_id) за единицу времени. Защищает от DDoS, брутфорса паролей, злоупотреблений API и снижает нагрузку на серверы.АлгоритмыFixed window — N запросов за фиксированный интервал (например, 100 в минуту). Прост, но уязвим к пиковым атакам на границах оконSliding window — скользящее окно, более равномерное распределениеToken bucket — клиент получает «жетоны» с фиксированной скоростью и тратит по одному на запрос. Допускает короткие burst-ыLeaky bucket — запросы обрабатываются равномерно, независимо от burst-овРеализацияХраните счётчики в Redis — он поддерживает атомарный инкремент и TTL. HTTP-ответ при превышении лимита: 429 Too Many Requests с заголовком Retry-After.

readonly — модификатор PHP 8.1, позволяющий записать свойство только один раз (в конструкторе) и запрещающий любые последующие изменения. Идеален для Value Objects и DTO — гарантирует неизменяемость без лишнего кода. Пример class Money { public function __construct( public readonly int $amount, public readonly string $currency, ) {} } $price = new Money(100, 'RUB'); echo $price->amount; // 100 $price->amount = 200; // Error: Cannot modify readonly property readonly class (PHP 8.2) PHP 8.2 добавил readonly class — все свойства класса автоматически становятся readonly. Не нужно писать модификатор для каждого. readonly class Point { public function __construct( public float $x, public float $y, ) {} }

Redis — in-memory хранилище данных со структурами string, hash, list, set, sorted set и stream. Поскольку все данные хранятся в RAM, операции выполняются за микросекунды. Чаще всего используется как кэш, брокер очередей и pub/sub-система.Типичные сценарииКеширование — сохранить результат тяжёлого SQL-запроса на N секундСессии — быстрое хранение сессий вместо базы данныхОчереди — надёжный брокер для фоновых задач; воркер читает задачи через BRPOP или StreamsRate limiting — атомарный инкремент счётчика запросов за временное окноPub/Sub — трансляция событий между сервисами в реальном времениПерсистентностьRedis хранит данные в памяти, но поддерживает два режима дампа на диск: RDB (снимки) и AOF (лог всех операций). Для кэша персистентность не критична — для очередей лучше включить AOF.

Repository — паттерн, изолирующий бизнес-логику от деталей хранения данных. Вместо того чтобы писать SQL-запросы или обращаться к ORM напрямую в сервисах, вся работа с БД инкапсулируется в отдельный класс-репозиторий.Что даётБизнес-логика не знает, откуда берутся данные: из MySQL, Redis или внешнего APIЛегко заменить реализацию в тестах на in-memory или mockЗапросы сосредоточены в одном месте — легче найти и оптимизироватьПростая структураinterface UserRepository { findById(int $id): ?User; save(User $user): void; } class SqlUserRepository implements UserRepository { ... }Когда не нуженВ небольших CRUD-приложениях Repository — излишнее усложнение. Оправдан там, где бизнес-логика сложна и нужна независимость от источника данных.

REST (Representational State Transfer) — архитектурный стиль для построения API поверх HTTP. Ресурсы адресуются через URL, а действия над ними — через стандартные HTTP-методы. REST — не протокол и не стандарт, а набор ограничений, которые делают API предсказуемым и масштабируемым.Ключевые принципыStateless — каждый запрос содержит всю необходимую информацию, сервер не хранит состояние между запросамиЕдиный интерфейс — GET читает, POST создаёт, PUT/PATCH обновляет, DELETE удаляетРесурсы — существительные в URL (/users/42), не глаголы (/getUser)Кешируемость — ответы могут кешироваться, снижая нагрузкуКоды ответов200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 422 Unprocessable Entity, 500 Internal Server Error — правильное их использование делает API самодокументируемым.

Rolling Update — стратегия обновления, при которой новая версия разворачивается постепенно: по одной или небольшими группами обновляются инстансы, при этом старая версия продолжает обрабатывать запросы. Нулевой downtime без удвоения ресурсов. Схема Начало: [v1][v1][v1][v1] Шаг 1: [v2][v1][v1][v1] ← один инстанс обновлён Шаг 2: [v2][v2][v1][v1] Шаг 3: [v2][v2][v2][v1] Конец: [v2][v2][v2][v2] Параметры maxUnavailable — сколько инстансов может быть недоступно одновременно maxSurge — сколько дополнительных инстансов разрешено запустить сверх нормы Проблема совместимости версий Во время rolling update одновременно работают и v1, и v2. Если v2 изменила схему БД — v1 может не понять новые данные. Решения: backward-compatible миграции или feature flags. Vs Blue-Green, Canary Rolling Update — наиболее бюджетный вариант (без дополнительных ресурсов). Blue-Green требует двойных ресурсов. Canary — тонкий контроль над распределением трафика.