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

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.ПреимуществаПолный audit trail: всегда знаем почему состояние такое, а не только какое оноМожно восстановить состояние на любой момент времениНовые 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 снова.