Монолит vs Микросервисы: в чем разница для QA? 👇
Архитектура
Монолит
• UI, бизнес-логика и БД — единое приложение
• Общая база данных
• Компоненты тесно связаны
Микросервисы
• Каждый сервис отвечает за свою бизнес-функцию
• У каждого сервиса может быть собственная БД
• Взаимодействие через API и очереди сообщений
Что тестировать?
Монолит
✅ Функциональность приложения
✅ Бизнес-логику
✅ Интеграцию модулей
✅ Работу с общей БД
Микросервисы
✅ API между сервисами
✅ Contract testing
✅ Kafka / RabbitMQ
✅ Консистентность данных
✅ Логи, tracing и мониторинг
✅ Отказоустойчивость сервисов
Надёжность
Монолит
❌ Ошибка может повлиять на всё приложение
❌ Единая точка отказа
Микросервисы
✅ Сбой чаще локализован
✅ Остальные сервисы продолжают работать
✅ Проще масштабировать отдельные компоненты
🔄 переход из монолита в микросервисы
Для QA появляются дополнительные проверки:
• регрессия после выделения сервиса;
• совместная работа монолита и новых сервисов;
• API и контрактов между сервисами;
• очередей сообщений;
• логов, мониторинга;
• отказоустойчивости и восстановления после сбоев.
Важно
В микросервисной архитектуре нет догмы, что у каждого сервиса должна быть отдельная физическая база данных. Рекомендуемый паттерн Database per Service, где каждый сервис владеет своими данными, но это может быть отдельная схема, отдельная БД или даже выделенные таблицы. Общая база тоже встречается, особенно при миграции с монолита, но это компромисс, который усиливает связанность сервисов. Главное, не количество баз, а независимость владения данными и границами сервиса.
Многие крупные продукты годами успешно работают на монолитной архитектуре. Переход к микросервисам обычно имеет смысл тогда, когда появляются независимые команды, отдельные релизы, требования к масштабированию и высокая нагрузка.
Из моего опыта
Монолит мне довелось тестировать один раз.
А вот с микросервисами работаю регулярно, и самая интересная часть для меня - интеграционное тестирование, поиск проблем во взаимодействии сервисов, анализ логов и проверка очередей.

Что вы тестируете монолит или микросервисы?

Ставь просто ❤️, если полезно 🔥

#QA #ТестированиеПО #qaengineer#тестирование #собеседование

REST (Representational State Transfer) - это архитектурный стиль для построения распределённых систем
REST API - архитектурный стиль проектирования программных интерфейсов
RESTful API - это термин, который использует строгое следование принципам REST

1️ Клиент-Сервер (Client-Server)
Полное разделение интересов.
Клиент → UI/UX
🖥️ Сервер → Данные и логика
Зачем: Независимое развитие и масштабирование.

2️⃣ Отсутствие состояния (Stateless)
Сервер не помнит предыдущие запросы. Каждый запрос самодостаточен.
Зачем: Надежность, простота балансировки нагрузки.
⚠️ Токены передаются в каждом запросе!

3️⃣ Кэшируемость (Cacheability)
Ответы должны явно маркироваться (Cache-Control, ETag).
Зачем: Снижение нагрузки, ускорение работы.
💡 Для QA: Проверяй заголовки кэша в Network / Application!

4️⃣ Единообразие интерфейса (Uniform Interface)
Единый стандарт взаимодействия:
• Идентификация ресурсов (URI)
• Манипуляция через представления (JSON)
• Самодостаточные сообщения
• Стандартные методы (GET, POST, PUT, DELETE)
• HATEOAS (ссылки в ответе)

5️⃣ Многоуровневая система (Layered System)
Архитектура из слоев (прокси, балансировщики, серверы). Клиент видит только шлюз.
Зачем: Безопасность, гибкость инфраструктуры.

6️⃣ Код по требованию (Code on Demand)
Сервер может передать исполняемый код (JS).
⚠️ Опционально и используется редко из-за рисков безопасности.

Какой принцип самый сложный для понимания или легко запоминающийся? Пиши в комментариях 👇

Ставь ❤️, если полезно!

А завтра планирую снова тесты провести, 🔥 для завтрашнего дня

Подготовка к собеседованию

Разбираем по полочкам (с опорой на CAP-теорему и документацию PostgreSQL, MongoDB, Redis, Cassandra, Neo4j).

РЕЛЯЦИОННЫЕ (SQL): PostgreSQL, MySQL
• Фиксированная схема (строгие типы данных)
• ACID-транзакции (Atomicity, Consistency, Isolation, Durability)
• Связи через JOIN и foreign keys
• Вертикальное масштабирование

📄 НЕРЕЛЯЦИОННЫЕ (NoSQL): 4 типа

1️⃣ ДОКУМЕНТНЫЕ (MongoDB)
Хранят JSON-документы. Гибкая схема.
→ Каталоги товаров, пользовательские профили, CMS

2️⃣ KEY-VALUE (Redis)
Пары ключ-значение. Молниеносная скорость.
→ Кэширование, сессии, рейтинги

3️⃣ КОЛОНОЧНЫЕ (Cassandra)
Данные по столбцам, не по строкам.
→ Временные ряды, логи, Big Data, IoT

4️ ГРАФОВЫЕ (Neo4j)
Узлы и связи между ними.
→ Социальные сети, рекомендации, fraud detection

️ CAP-ТЕОРЕМА: ВЫБЕРИ 2 ИЗ 3
• Consistency (согласованность)
• Availability (доступность)
• Partition tolerance (устойчивость к разделению)

SQL обычно = CA (жертвуют масштабированием)
NoSQL = AP или CP (жертвуют мгновенной согласованностью ради доступности или наоборот)

🎯 КОГДА ЧТО ВЫБИРАТЬ?

SQL, если:
✓ Сложные транзакции (банкинг, заказы)
✓ Строго структурированные данные
✓ Важна целостность (ACID)
✓ Много связей между сущностями

NoSQL, если:
✓ Неструктурированные данные
✓ Горизонтальное масштабирование
✓ Высокая скорость записи
✓ Схема часто меняется

💡 ГЛАВНОЕ
Нет «лучшей» базы данных. Есть подходящая под твою задачу. Часто в одном проекте используют и SQL, и NoSQL (polyglot persistence).

👇 С какой базой данных ты работаешь чаще всего? Пиши в комментариях!

#базыданных #SQL #NoSQL #тестированиепо #QA