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

E2E (End-to-End) тест — автоматична симуляція дій реального користувача в браузері: заповнити форму, натиснути кнопку, перевірити, що дані з'явились. Перевіряє весь стек від UI до БД.Коли потрібенКритичні сценарії: реєстрація, логін, оформлення замовлення, оплатаСкладні UI-потоки з багатьма крокамиРегресійні тести після великих змінПопулярні інструментиPlaywright (Microsoft) — підтримує Chromium, Firefox, WebKit. Найпопулярніший заразCypress — JavaScript, відмінний DX, тільки Chromium-basedSelenium — старіший, підтримує всі браузериНедолікиE2E тести повільні (секунди на тест), крихкі (залежать від UI-деталей), вимагають запущеного застосунку. Тому їх тримають мало і запускають рідше, ніж unit-тести.

ELK Stack — Elasticsearch + Logstash + Kibana. Платформа для централізованого збору, зберігання, пошуку і візуалізації логів з усіх сервісів. Сучасний варіант — Elastic Stack з додаванням Beats (агенти збору). Компоненти Filebeat / Fluentd — агент на кожному сервері, читає лог-файли і відправляє далі Logstash — парсинг, фільтрація, трансформація логів (можна замінити на Fluentd або Vector) Elasticsearch — індексує і зберігає логи. Надає повнотекстовий пошук Kibana — веб-інтерфейс для пошуку по логах, дашборди, алерти Альтернативи Grafana Loki — легший, зберігає лише мітки і рядки (не індексує вміст) Datadog, Splunk — хмарні SaaS-рішення Структуровані логи Логуйте JSON замість plain text. Тоді Elasticsearch автоматично індексує поля і можна шукати: level:error AND service:payments AND duration:>1000.

Event Loop — механізм виконання асинхронного коду в однопотокових середовищах (JavaScript, Node.js). Дозволяє обробляти тисячі одночасних з'єднань без потоків, виконуючи I/O-операції «у фоні» через ОС.Як працюєCall Stack — синхронний код виконується послідовноПри зустрічі async-операції (HTTP-запит, setTimeout) — вона передається в Web API/libuv і виконується поза основним потокомКоли операція завершена — колбек потрапляє в Callback QueueEvent Loop перевіряє: якщо Call Stack порожній — переносить колбек у стекMacrotasks vs MicrotasksMicrotasks (Promise.then, queueMicrotask) виконуються перед наступним macrotask (setTimeout, setInterval). Тому Promise.resolve().then(fn) виконається раніше за setTimeout(fn, 0).

Event Sourcing — підхід до зберігання стану, при якому зберігаються не поточні значення, а послідовність подій, що привели до цього стану. Поточний стан отримується «відтворенням» (replay) всіх подій з початку.ПрикладЗамість зберігання balance = 1500 — зберігаємо події: AccountCreated(0), MoneyDeposited(2000), MoneyWithdrawn(500). Баланс = 0 + 2000 − 500 = 1500.ПеревагиПовна аудит-трейл: завжди знаємо чому стан такий, а не лише який він єМожна відновити стан на будь-який момент часуНові read-моделі будуються replay'єм існуючих подійСкладнощіEventstore зростає нескінченно — потрібні snapshotsСкладна еволюція схеми подій (versioning)Висока складність реалізації

Event-Driven Architecture (EDA) — архітектурний стиль, де сервіси взаємодіють через події, а не через прямі виклики. Одна подія (OrderPlaced) може запустити кілька незалежних обробників паралельно: відправку email, оновлення складу, запис аналітики. Переваги Слабке зв'язування — видавець події не знає про підписників Масштабованість — обробники можна масштабувати незалежно Розширюваність — новий обробник підключається без змін у видавця Компоненти Producer — генерує і публікує подію Event Broker — маршрутизує (Kafka, RabbitMQ) Consumer — підписується і обробляє Складнощі Відлагодження: складніше відстежити потік виконання Eventual Consistency: стан різних сервісів тимчасово розходиться Гарантії доставки: at-least-once потребує ідемпотентних обробників

Eventual Consistency (узгодженість у підсумку) — гарантія в розподілених системах: якщо немає нових записів, усі репліки зрештою збіжуться до одного стану. Але в будь-який конкретний момент різні вузли можуть показувати різні значення.ПрикладВи лайкнули пост у соцмережі. Лічильник одразу змінився для вас (local replica), але ваш друг в іншому регіоні ще бачить стару кількість — і побачить оновлену через секунду-дві, коли реплікація дійде.Сильна vs слабка узгодженістьStrong Consistency — після запису всі читання одразу бачать нове значення. Дорожче, вища латентністьEventual Consistency — дешевше і швидше, але короткий час невідповідності (stale reads)CRDTConflict-free Replicated Data Types — спеціальні структури даних, де конфлікти між репліками вирішуються автоматично без координації. Наприклад, distributed counter, де кожен вузол незалежно інкрементує своє значення.

EXPLAIN — SQL-команда, що показує, як СУБД планує виконати запит: які таблиці і в якому порядку читатиме, які індекси використає, скільки рядків скануватиме. Незамінний інструмент для оптимізації повільних запитів.Базовий синтаксисEXPLAIN SELECT * FROM orders WHERE user_id = 42 AND status = 'paid'; -- детальніше з аналізом реального виконання: EXPLAIN ANALYZE SELECT ...;На що звертати увагуtype: найгірший — ALL (full table scan), найкращий — const, ref, eq_refrows: оцінка кількості рядків. Мільйони при ALL — проблемаExtra: Using filesort і Using temporary — сигнали проблемkey: який індекс використано (NULL — індекс не використаний)Покроковий підхідЗнайдіть запит з повільним часом виконання → EXPLAIN → знайдіть ALL scan → додайте індекс → перевірте EXPLAIN знову.