Вопросы по микросервисам, REST/SOAP/gRPC API, SQL индексам, очередям сообщений (Kafka) и интеграционным контрактам.
* **Бизнес-аналитик (BA)** фокусируется на бизнес-процессах, организационных изменениях и решении бизнес-задач. Он работает на уровне «Что нужно бизнесу?». * **Системный аналитик (SA)** переводит бизнес-требования на язык системной архитектуры, проектирует API, структуры БД, интеграции и контракты. Он работает на уровне «Как это будет реализовано технически в ИТ-системах?».
* **Монолит**: Приложение собирается и деплоится как единое целое. Простая разработка на старте, высокая скорость работы внутри приложения. Минусы: сложно масштабировать, падение одного модуля ломает все приложение, долгий билд. * **Микросервисы**: Система разбита на небольшие независимые сервисы, общающиеся по сети. Плюсы: масштабируемость, независимый деплой, изоляция сбоев. Минусы: сложность инфраструктуры, сетевые задержки, трудности с распределенными транзакциями и консистентностью данных.
API (Application Programming Interface) — контракт взаимодействия программных компонентов. Стили: * **REST**: Архитектурный стиль на основе протокола HTTP, сущностей (ресурсов) и стандартных методов. JSON/XML. * **SOAP**: Строгий XML-протокол со встроенными стандартами безопасности (WS-Security) и описанием через WSDL. Используется в банках. * **gRPC**: Быстрый бинарный протокол от Google на базе HTTP/2 и Protocol Buffers. Используется для inter-service (back-to-back) коммуникации. * **GraphQL**: Язык запросов к API, позволяющий клиенту запросить только нужные поля в рамках одного запроса.
REST базируется на шести ограничениях: 1. **Клиент-Сервер (Client-Server)**: Разделение интерфейса и данных. 2. **Отсутствие состояния (Stateless)**: Запросы не зависят друг от друга, сервер не хранит сессию клиента. 3. **Кэширование (Cacheable)**: Ответы сервера должны быть помечены как кэшируемые. 4. **Единообразие интерфейса (Uniform Interface)**: Использование URI для идентификации ресурсов и HTTP методов для действий. 5. **Слоистая система (Layered System)**: Клиент общается с сервером и не знает, сколько промежуточных слоев (прокси, балансировщики) находится между ними. 6. **Код по запросу (Code on Demand)**: Передача исполняемого кода (необязательно).
* **GET**: Получение данных. Идемпотентен и безопасен. * **POST**: Создание ресурса. Не идемпотентен (два POST запроса создадут две записи). * **PUT**: Полная замена ресурса. Идемпотентен. * **PATCH**: Частичное обновление ресурса. Не идемпотентен (в общем случае). * **DELETE**: Удаление ресурса. Идемпотентен. **Идемпотентность** — свойство метода при многократном повторении давать один и тот же результат, как при однократном вызове.
Нормализация — это процесс организации структуры БД для исключения избыточности данных и аномалий вставки/удаления/обновления. * **1NF**: Все поля атомарны, нет повторяющихся групп. * **2NF**: Удовлетворяет 1NF, и все неключевые поля зависят от полного первичного ключа. * **3NF**: Удовлетворяет 2NF, и нет транзитивных зависимостей неключевых полей друг от друга.
Транзакция — логическая единица работы с БД, выполняемая целиком или не выполняемая вовсе. Свойства ACID: * **A (Atomicity)**: Атомарность — транзакция завершается успешно (`COMMIT`) или полностью откатывается (`ROLLBACK`). * **C (Consistency)**: Согласованность — БД переходит из одного валидного состояния в другое. * **I (Isolation)**: Изолированность — параллельные транзакции не влияют друг на друга. * **D (Durability)**: Долговечность — закоммиченные данные не пропадут при сбое сервера.
* **SQL БД**: Хранят данные в виде связанных таблиц со строгой схемой. Поддерживают ACID и сложные JOIN запросы. Пример: PostgreSQL, MySQL. * **NoSQL БД**: Гибкое хранение без фиксированной схемы. Отлично масштабируются горизонтально. Типы: документные (MongoDB), ключ-значение (Redis), колоночные (Cassandra), графовые (Neo4j).
Брокер сообщений — промежуточное ПО для асинхронного обмена сообщениями между сервисами. Декоплирует отправку и получение данных. * **RabbitMQ**: Традиционный брокер очередей (Smart Broker, Dumb Consumer). Сообщение удаляется после подтверждения обработки. Поддерживает сложную маршрутизацию. * **Apache Spark / Kafka**: Распределенный лог коммитов (Dumb Broker, Smart Consumer). Сообщения хранятся на диске и могут быть перечитаны заново. Обладает высокой пропускной способностью.
Схема должна содержать базовые сущности и связи: * `Users` (пользователи) - связь один-ко-многим с `Orders`. * `Orders` (заказы) - связь один-ко-многим с `OrderItems`. * `Products` (товары) - связь один-ко-многим с `OrderItems`. * `OrderItems` (позиции в заказе) — промежуточная таблица-развязка связи многие-ко-многим между заказами и товарами (хранит `order_id`, `product_id`, `quantity`, `price_at_purchase`).
JWT (JSON Web Token) — открытый стандарт для безопасной передачи информации между сторонами в виде JSON-объекта. Состоит из 3 частей, разделенных точками: 1. **Header (Заголовок)**: Алгоритм подписи (например, HS256). 2. **Payload (Полезная нагрузка)**: Данные пользователя (User ID, роли, срок действия token expiration). 3. **Signature (Подпись)**: Хэш хедера, пейлоуда и секретного ключа сервера. Предотвращает подделку токена. Хранится на клиенте обычно в `LocalStorage` или `HttpOnly Cookies`.
OAuth 2.0 — фреймворк авторизации, позволяющий стороннему приложению получить ограниченный доступ к ресурсам пользователя без передачи ему пароля (например, «Войти через Google»). **Роли**: Resource Owner (пользователь), Client (приложение), Authorization Server (сервер авторизации Google), Resource Server (сервер ресурсов с API).
Спецификация OpenAPI (Swagger) описывается в формате YAML или JSON и содержит: * Базовую информацию об API (версия, описание, URL сервера). * Пути (Paths / Endpoints) запросов (например, `/api/v1/users`). * HTTP методы для каждого пути. * Параметры запроса (Query, Path, Headers). * Схему тела запроса (Request Body). * Схемы ответов (Responses) для разных статус-кодов (200, 400, 500) с примерами данных.
Балансировщик распределяет входящие сетевые запросы между пулом бэкенд-серверов для повышения надежности и отказоустойчивости системы. **Round Robin**: Алгоритм циклического перебора. Запросы направляются серверам последовательно по кругу (сервер 1, сервер 2, сервер 3, снова сервер 1). Есть модификация Weighted Round Robin, учитывающая мощность серверов.
CAP-теорема утверждает, что в распределенной системе невозможно одновременно обеспечить более двух из трех свойств: * **C (Consistency)**: Согласованность данных — во всех узлах в один момент времени данные одинаковы. * **A (Availability)**: Доступность — любой запрос к системе возвращает успешный ответ. * **P (Partition tolerance)**: Устойчивость к разделению — система продолжает работать при сбое сетевой связи между узлами. В реальных сетях сетевые сбои неизбежны, поэтому система всегда выбирает либо AP (доступность без гарантии строгой согласованности), либо CP (согласованность за счет блокировки ответов при сбое связи).
* **Синхронное**: Клиент отправляет запрос к сервису и блокируется (ждет ответа), прежде чем продолжить выполнение своей логики. Пример: HTTP/REST вызов. * **Асинхронное**: Клиент отправляет сообщение (например, в очередь) и сразу продолжает работу, не дожидаясь ответа. Ответ может прийти позже через механизм колбэков или событий. Пример: Kafka/RabbitMQ.
CORS — механизм безопасности браузеров, который ограничивает запросы веб-страницы к домену, отличному от того, с которого страница была загружена. Чтобы разрешить запросы, сервер должен прислать правильные заголовки ответа (например, `Access-Control-Allow-Origin: *` или конкретный домен клиента).
* **OLTP (Online Transaction Processing)**: Системы транзакционной обработки. Оптимизированы для сотен тысяч быстрых точечных запросов на чтение/запись строк. Хранят актуальное состояние данных. Пример: реляционные СУБД в ядре сервиса. * **OLAP (Online Analytical Processing)**: Системы аналитической обработки. Оптимизированы для сложных агрегирующих запросов над историческими данными за большой период (суммы, средние по миллионам строк). Пример: ClickHouse, Snowflake.
При асинхронной обработке транзакций используются очереди очередей: * **Retry Queue**: Очередь для сообщений, обработка которых завершилась временным сбоем (сетевой таймаут). Сообщение пробуется обработать снова с задержкой (backoff). * **DLQ (Dead Letter Queue)**: Очередь «мертвых писем». Сюда перемещаются сообщения, исчерпавшие лимит попыток обработки или содержащие неустранимые ошибки (битый JSON). DLQ анализируется инженерами вручную.
1. Реализовать паттерн **Circuit Breaker** (предохранитель): если количество ошибок превышает порог, временно прекратить запросы к внешнему сервису и возвращать заглушку или ошибку из кэша, снижая нагрузку. 2. Реализовать асинхронную обработку через очередь с повторными попытками (Retry policy с экспоненциальным затуханием). 3. Оповестить внешнюю команду интеграции, прикрепив логи с ID запросов (correlation ID) и временем сбоев.
Идемпотентность гарантирует, что повторные запросы с одним и тем же ключом идемпотентности (например, UUID транзакции) не приведут к повторному созданию данных или двойному списанию денег. Сервер сохраняет результат первой успешной обработки запроса по его ключу в кэш и при повторном запросе просто отдает сохраненный ответ.
* **JSON**: Легковесный текстовый формат обмена данными. Читается быстрее, имеет меньший объем, нативно поддерживается JavaScript. Используется в REST API. * **XML**: Более тяжелый текстовый формат с теговой структурой. Поддерживает валидацию схем (XSD), пространства имен, ссылки на сущности. Используется в SOAP API и корпоративных интеграциях.
Денормализация — намеренное внесение избыточности данных в нормализованную структуру БД для ускорения операций чтения. Полезна в высоконагруженных системах или OLAP хранилищах, когда частые тяжелые `JOIN` запросы перегружают сервер. Ценой расхода памяти и усложнения логики записи мы выигрываем в скорости получения данных.
Redis — нереляционная СУБД класса Key-Value, работающая полностью в оперативной памяти (In-Memory Database), с возможностью сохранения снимков на диск. **Применение**: Кэширование тяжелых запросов, хранение сессий пользователей, реализация счетчиков, очередей сообщений и распределенных блокировок.
Алгоритм балансировки нагрузки, при котором хэш-функция вычисляет хэш-код IP адреса клиента и на его основе сопоставляет его с конкретным сервером в пуле. Это гарантирует, что запросы от одного и того же клиента всегда будут приходить на один и тот же бэкенд-сервер (полезно для сохранения локального кэша сессий).
Подход к разработке веб-приложений, при котором интерфейс собирается из нескольких независимых блоков (микрофронтов), разрабатываемых и разворачиваемых отдельными командами. Это аналог микросервисов для клиентской стороны.
Требования к миграции должны содержать: 1. Источник данных (Source) и Целевая система (Target). 2. Карта соответствия полей (Mapping): какие колонки старой таблицы переносятся в какие колонки новой с правилами трансформации типов. 3. Сценарии валидации перенесенных данных (сверка контрольных сумм, подсчет количества записей). 4. План отката (Rollback plan) на случай сбоя в процессе миграции.
DWH — корпоративное хранилище данных, предназначенное для целей бизнес-аналитики (BI). В него собираются, очищаются и консолидируются исторические данные из различных операционных систем компании. Оптимизировано для тяжелых аналитических SQL-запросов.
ETL (Extract, Transform, Load) — процессы извлечения данных из источников, их трансформации (очистка, нормализация, агрегация) и загрузки в целевое хранилище (DWH).
Sequence Diagram (Диаграмма последовательности) описывает порядок обмена сообщениями во времени. Аналитик указывает: * Участников (Lifelines) взаимодействия: Пользователь, API Gateway, Сервер, БД. * Направление сообщений (Синхронные вызовы — сплошные стрелки с залитым наконечником, асинхронные — простые стрелки, ответы — пунктирные). * Логические блоки условий (`alt` / `opt`) и циклов (`loop`).
* **Монолит**: Все модули находятся в одном процессе и вызывают друг друга напрямую в памяти (in-memory calls). Интеграция проста, транзакции локальны и надежны (ACID). * **Микросервисы**: Общаются по сети (сетевые вызовы HTTP/gRPC/очереди). Возникают сетевые задержки, риски падения сети, проблемы распределенных данных. Требуется проектирование отказоустойчивости (Circuit Breaker, Idempotency) и распределенных транзакций (Saga).
* **REST API (синхронное)**: Клиент отправляет запрос и ждет ответа от сервера. Если сервер недоступен, запрос падает. Подходит для мгновенных операций (получить баланс, войти на сайт). * **Message Queue (асинхронное)**: Отправитель кладет сообщение в очередь брокера и сразу продолжает работу. Брокер гарантирует доставку сообщения получателю, даже если тот временно недоступен. Подходит для фоновой обработки (генерация отчетов, отправка писем, обработка платежей).
gRPC — фреймворк удаленного вызова процедур (RPC) от Google: * **Транспорт**: Использует HTTP/2 (поддержка двунаправленного стриминга, сжатие заголовков, мультиплексирование запросов по одному соединению). * **Формат данных**: Бинарный формат **Protocol Buffers** вместо текстового JSON/XML. Данные сжимаются сильнее, сериализация происходит в разы быстрее. * **Контракт**: Строгое описание контракта в `.proto` файлах, на основе которых автоматически генерируется код клиентов и серверов для разных языков программирования.
OpenAPI — спецификация для описания REST API в формате YAML или JSON. Системный аналитик описывает: * Пути (Endpoints) и поддерживаемые HTTP-методы (GET, POST). * Входные параметры (Query, Path, Headers). * Схемы запросов и ответов (структура JSON объектов, обязательные поля, типы данных, валидация полей). * Коды ответов (200 OK, 400 Bad Request, 401 Unauthorized). Это позволяет автоматически генерировать интерактивную документацию (Swagger UI) и заглушки для тестов.
* **SOAP**: Протокол со строгими стандартами безопасности (WS-Security) и транзакционности (WS-AtomicTransaction). Использует только XML. Описание контракта в WSDL-файле. Работает поверх любых протоколов (HTTP, SMTP, JMS). Популярен в финтехе и энтерпрайзе. * **REST**: Архитектурный стиль. Проще в реализации. Использует любые форматы (обычно JSON). Работает поверх HTTP. Меньше накладных расходов, легче кэшируется.
GraphQL — язык запросов к API от Facebook: * **Гибкость**: Клиент сам описывает в запросе структуру нужных ему данных, и сервер возвращает ровно эти поля (решает проблему избыточной загрузки over-fetching или нехватки данных under-fetching). * **Один эндпоинт**: Все запросы идут на один URL (обычно POST `/graphql`). * **Когда использовать**: Сложные системы со множеством связей, мобильные клиенты с медленным интернетом, где критично минимизировать число сетевых запросов.
* **Кластеризованный индекс (Clustered)**: Определяет физический порядок хранения строк таблицы на диске. Данные таблицы упорядочены по ключу индекса. Может быть только один на таблицу (обычно это Primary Key). * **Некластеризованный индекс (Non-clustered)**: Создает отдельную структуру данных (B-Tree), где листья дерева хранят значения ключа индекса и указатель на физическую строку в таблице (RID или ключ кластеризованного индекса). Таких индексов может быть много.
Уровни изолированности защищают данные от параллельного изменения (стандарт SQL): 1. **Read Uncommitted**: Потоки видят незакоммиченные изменения других транзакций (проблема **Грязного чтения / Dirty Read**). 2. **Read Committed**: Видны только закоммиченные данные. Защищает от грязного чтения, но возможна проблема **Неповторяющегося чтения (Non-repeatable Read)**. 3. **Repeatable Read**: Повторное чтение строки внутри транзакции вернет те же данные. Возможна проблема **Фантомного чтения (Phantom Read)** — появление новых строк. 4. **Serializable**: Полная изоляция. Транзакции выполняются последовательно. Самый медленный уровень.
ACID гарантирует надежность транзакций баз данных: * **A (Atomicity)**: Атомарность. Транзакция выполняется полностью или не выполняется вообще (все изменения откатываются при сбое). * **C (Consistency)**: Согласованность. Транзакция переводит БД из одного валидного состояния в другое, не нарушая констрейнты и бизнес-правила. * **I (Isolation)**: Изолированность. Параллельные транзакции не должны влиять друг на друга. * **D (Durability)**: Долговечность. Если транзакция закоммичена, изменения сохраняются на диске и не пропадут при сбое питания.
* **RabbitMQ**: Классический брокер («умный брокер, глупый клиент»). Сообщения доставляются консьюмерам и сразу удаляются из очереди после подтверждения (ACK). Поддерживает гибкую маршрутизацию (Routing keys, Exchanges). * **Apache Kafka**: Распределенный лог сообщений («глупый брокер, умный клиент»). Сообщения пишутся в лог на диске и хранятся там заданное время (retention period), их можно перечитать заново. Клиент сам хранит свой оффсет (указатель чтения). Оптимизирован под огромные потоки данных (Event streaming).
Интеграция должна быть отказоустойчивой: * **Идемпотентность**: Отправлять уникальный ключ операции (например, UUID транзакции) в заголовке `Idempotency-Key`. Если платежка получит запрос дважды из-за сбоя сети, она спишет деньги только один раз. * **Retries с экспоненциальным бэкоффом**: Повторять запросы при сетевых ошибках (код 503, таймаут) с увеличивающейся паузой (например, через 1, 2, 4, 8 секунд) во избежание перегрузки внешнего сервиса. * **Таймауты**: Ограничивать время ожидания ответа (Connection/Read Timeout), чтобы наши потоки не зависали.
CDC (захват измененных данных) — паттерн интеграции, при котором изменения в базе данных (INSERT, UPDATE, DELETE) автоматически отслеживаются и транслируются в другие системы на основе чтения бинарных логов репликации БД (например, WAL в PostgreSQL или binlog в MySQL). Это позволяет синхронизировать данные (например, наполнять ElasticSearch для поиска) асинхронно, без нагрузки на основное приложение.
* **Репликация**: Копирование всей базы данных на несколько серверов (реплик). Используется для повышения отказоустойчивости (если упадет один сервер, другие продолжат работу) и масштабирования **чтения** (запросы на чтение распределяются по репликам). * **Шардирование**: Разделение базы данных на части. Каждая часть (шард) хранит только свое подмножество строк. Используется для масштабирования **записи** и объема данных, когда вся БД физически не помещается на один сервер.
Sequence Diagram визуализирует взаимодействие объектов/систем во времени: * Отображает участников процесса (клиент, API Gateway, микросервисы, БД). * Показывает стрелками вызовы методов или HTTP-запросы и ответы. * Помогает наглядно спроектировать сложный интеграционный сценарий, выявить лишние сетевые запросы, определить места обработки ошибок и синхронные/асинхронные блоки вызовов.
1. **Client-Server (Клиент-сервер)**: Разделение интерфейса и хранения данных. 2. **Stateless (Без сохранения состояния)**: Сервер не хранит контекст клиента. Каждый запрос содержит всю необходимую информацию для его обработки. 3. **Cacheable (Кэширование)**: Ответы сервера должны явно помечаться как кэшируемые или нет. 4. **Uniform Interface (Единый интерфейс)**: Использование стандартных методов (GET, POST), URI ресурсов, самоописываемые сообщения. 5. **Layered System (Многоуровневая система)**: Клиент не знает, общается он напрямую с сервером или с посредниками (балансировщиками, прокси). 6. **Code on Demand (Код по запросу — опционально)**: Передача исполняемого кода (например, JS-скриптов) на клиент.
* **Long Polling**: Клиент делает HTTP-запрос, сервер держит его открытым, пока не появятся новые данные. После ответа клиент сразу делает новый запрос. Устаревший, ресурсоемкий подход. * **SSE (Server-Sent Events)**: Однонаправленный поток данных от сервера к клиенту поверх стандартного HTTP. Сервер оставляет соединение открытым и шлет текстовые события. Проще в реализации. * **WebSockets**: Двунаправленный, полнодуплексный протокол поверх TCP. Клиент и сервер могут слать сообщения друг другу в любой момент с минимальными накладными расходами. Идеально для чатов и мультиплеера.
* **Round Robin**: Запросы распределяются по серверам строго по очереди по кругу. Простой алгоритм, не учитывающий текущую нагрузку на сервера. * **Weighted Round Robin**: Добавляет вес серверам (более мощные сервера получают больше запросов). * **Least Connections**: Направляет входящий запрос на сервер с наименьшим количеством активных соединений в данный момент. Оптимально для тяжелых запросов с разным временем выполнения.
Нормализация устраняет избыточность и аномалии данных в реляционных БД: * **1NF**: Все атрибуты атомарны (нет списков/массивов в ячейках), строки уникальны. * **2NF**: Находится в 1NF и все неключевые поля зависят от полного первичного ключа (актуально для составных ключей). * **3NF**: Находится в 2NF и все неключевые поля зависят только от первичного ключа, транзитивные зависимости отсутствуют (например, если поле зависит от другого неключевого поля, его нужно вынести в отдельную таблицу).
JWT (JSON Web Token) состоит из трех частей, разделенных точками: `header.payload.signature`: 1. **Header (Заголовок)**: Тип токена (JWT) и алгоритм шифрования (например, HS256). 2. **Payload (Полезная нагрузка)**: Данные пользователя (id, роли, время жизни токена). 3. **Signature (Подпись)**: Хэш от заголовка и полезной нагрузки, зашифрованный секретным ключом сервера. * **Валидация**: Серверу не нужно обращаться в БД для проверки JWT. Он берет header и payload пришедшего токена, генерирует подпись своим секретным ключом и сравнивает ее с подписью в токене. Если они совпадают и время жизни токена не истекло, токен валиден.
JSON Schema — это стандарт описания структуры JSON-документов. Аналитик использует ее для спецификации контрактов API. Она описывает, какие поля должны быть в JSON, их типы (string, number, boolean), обязательность полей (`required`), формат данных (например, `email` или `date-time`) и допустимые диапазоны значений. Разработчики используют JSON Schema для автоматической валидации входящих запросов на уровне API Gateway.