Словник веб-розробника

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 по корпоративній документації, пошук у великій базі знань, chatbot що відповідає на питання по продукту.

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, 'UAH'); 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 — тонший контроль над розподілом трафіку.