4824. В системе из 5 микросервисов при каждом обновлении данных нужно уведомлять 3 других сервиса. Прямые вызовы привели к большой связанности и падению одного сервиса, блокирующему других. Какой архитектурный стиль снизит связанность?
Anonymous Quiz
1%
Перейти на синхронные вызовы с ретраями
99%
Внедрить событийно-ориентированную архитектуру, где сервисы публикуют события в брокер
0%
Сделать всё в одном монолите
0%
Использовать общую базу данных для уведомлений
Прямые синхронные вызовы между сервисами создают жесткую связанность. Когда сервис А вызывает Б, В, Г, то падение любого из них может затронуть А. Событийная архитектура решает это.
Event-driven
Сервис-источник публикует событие в брокер (Kafka, RabbitMQ).
Подписчики (другие сервисы) получают события асинхронно.
Источник не знает о подписчиках и не ждёт ответа.
Отказ одного подписчика не влияет на источник и других.
Почему это снижает связанность
Слабая связанность — публикация события и его обработка разделены.
Отказоустойчивость — брокер буферизует события, упавший подписчик получит их при восстановлении.
Легко добавлять новых подписчиков без изменения источника.
Почему не другие
A — ретраи не решат связанность.
C — монолит против микросервисной идеи.
D — общая БД создаёт другую связанность.
Реальный пример
Upwork перешёл на event-driven и ускорил доставку уведомлений в реальном времени.
Вывод аналитика
Событийная архитектура — стандарт для слабо связанных микросервисов. Аналитик должен в требованиях указывать асинхронное взаимодействие для всех бизнес-событий, не требующих немедленного ответа.
Please open Telegram to view this post
VIEW IN TELEGRAM
4825. Вам нужно оценить стоимость разработки системы для аренды самокатов. Бизнес-функции: «заблокировать самокат», «начать поездку», «завершить поездку», «списать оплату». Какой метод позволит измерить объём требований независимо от технологии?
Anonymous Quiz
10%
Количество пользовательских историй
82%
Метод COSMIC – считаем функциональные процессы, триггеры и объекты данных
1%
Количество экранов в прототипе
7%
Стори-поинты на основе усреднения
Заказчикам нужна объективная оценка размера требований до начала разработки. Метод COSMIC позволяет измерить функциональный размер в единицах CFP (COSMIC Function Points) на основе логики данных, независимо от языка и платформы.
Как работает COSMIC (упрощённо)
Выделяем функциональные процессы (например, «Начать поездку»).
Для каждого процесса определяем триггер (событие, инициирующее процесс – например, пользователь отсканировал QR-код).
Определяем объекты данных, которые процесс читает или изменяет (например, состояние самоката, ID пользователя, временная метка).
Каждое перемещение данных (вход, выход, чтение, запись) – 1 CFP.
В примере с самокатом:
«Начать поездку»: триггер – сканирование; читается статус самоката, записывается начало поездки, обновляется счётчик. Это даст, скажем, 4 CFP.
Суммируя по всем процессам, получим объективный размер.
Почему не другие варианты
A (количество историй) – зависит от степени детализации, субъективно.
C (количество экранов) – не отражает сложность логики.
D (стори-поинты) – относительная оценка, не переносится между проектами.
Реальный кейс
Крупный банк использовал COSMIC для оценки размера кредитного конвейера. Оказалось, что оценка в CFP отличается от экспертной на 15%, но зато прозрачна для заказчика.
Вывод
Аналитик, владеющий COSMIC, может дать объективную оценку размера требований и обосновать бюджет.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2❤1
4826. Вам нужно синхронизировать данные из реляционной OLTP-базы в аналитическое хранилище (DWH) с минимальной задержкой (< 5 секунд). Традиционный ETL ночью не подходит. Какой подход обеспечит почти реальное время и не нагрузит исходную систему?
Anonymous Quiz
1%
Периодический SELECT всех изменённых строк по флагу
95%
Change Data Capture (CDC) через чтение лога транзакций (например, Debezium + Kafka)
1%
Триггеры на каждую таблицу
2%
Отказ от синхронизации, использовать прямое чтение из OLTP для отчётов
Периодический SELECT из большой OLTP-базы создаёт нагрузку и не обеспечивает задержку 5 секунд. Триггеры замедляют транзакции прямо в продовой системе.
Решение – CDC
Change Data Capture читает журнал транзакций (WAL в PostgreSQL, binlog в MySQL) и отправляет изменения (INSERT, UPDATE, DELETE) в Kafka. Потребитель (например, коннектор к ClickHouse) воспроизводит их в DWH с задержкой миллисекунды.
Преимущества
Минимальная нагрузка на исходную БД (читается уже сформированный лог).
Гарантированный порядок и сохранность (можно воспроизвести с любого смещения).
Не требует изменений в таблицах (ни триггеров, ни флагов).
Почему не другие варианты
A – высокий load, не даст 5 секунд.
C – триггеры замедляют вставку/обновление.
D – прямое чтение из OLTP убивает производительность аналитики.
Реальный пример
В крупном ритейлере CDC + Kafka синхронизирует 5000 изменений/сек с задержкой 1 секунда.
Требования аналитика
Использовать логическую репликацию или инструмент типа Debezium.
Обеспечить идемпотентность в целевой системе.
Please open Telegram to view this post
VIEW IN TELEGRAM
4827. У вас 50 микросервисов. Параметр (например, таймаут вызова внешнего API) нужно изменить в 30 из них. Как это сделать без передеплоя каждого сервиса?
Anonymous Quiz
3%
Перекомпилировать каждый сервис с новым значением и перевыкатить
87%
Хранить конфигурацию в централизованном сервере и читать её при старте / по подписке на обновления
2%
Послать сигнал SIGUSR1 каждому сервису
8%
Использовать глобальную переменную окружения на всех серверах
Если параметры зашиты в код или переменные окружения на каждом сервере, изменение требует передеплоя десятков сервисов – долго и рискованно.
Централизованная конфигурация
Сервисы при старте обращаются к серверу конфигурации (Spring Cloud Config, Consul, etcd) и получают значения. Некоторые системы позволяют обновлять конфигурацию на лету через механизм watch (сервисы подписываются на изменения). Kubernetes ConfigMap можно обновить, но требуется перезапуск подов (или reinterpret средствами operator).
Преимущества
Централизованное управление одной точкой.
Возможность версионирования и отката конфигурации.
Без передеплоя (если сервис перечитывает конфиг по сигналу или периодически).
Почему не подходят другие
A – передеплой каждого сервиса при каждом изменении параметра.
C – нет стандартного механизма для любого языка.
D – глобальные env подразумевают остановку сервисов.
Реальный пример
Netflix использует Archaius + свой сервер конфигурации, чтобы управлять тысячами сервисов.
Вывод аналитика
В требованиях к архитектуре нужно указать: «Конфигурация должна быть вынесена из кода и управляться централизованно».
Please open Telegram to view this post
VIEW IN TELEGRAM
ХОЧЕШЬ ПОСТОЯННО БЫТЬ В КУРСЕ И ДЕРЖАТЬ РУКУ НА ПУЛЬСЕ НОВИНОК AI & IT ?! Технологии не ждут. А ты?
Каждую неделю — десятки обновлений. То, что вчера делали часами, сегодня нейросеть делает за минуты. Вопрос только в том, узнаешь ли ТЫ об этом первым?
Пока большинство спит, лишь немногие тестируют новые связки и вырываются вперёд. Хочешь быть среди них?
Забирай ПОДБОРКУ со свежими ИИ-инструментами и фишками. Без воды — только то, что реально упрощает работу.
👉 Делимся знаниями и аудиторией — растём вместе ⚡️ Забирай ПАПКУ бесплатно. * Отписаться можно в любой момент. Остаться — тоже. ✔️
Не выпадай из обоймы - будь всегда на острие ! 📌
Каждую неделю — десятки обновлений. То, что вчера делали часами, сегодня нейросеть делает за минуты. Вопрос только в том, узнаешь ли ТЫ об этом первым?
Пока большинство спит, лишь немногие тестируют новые связки и вырываются вперёд. Хочешь быть среди них?
Забирай ПОДБОРКУ со свежими ИИ-инструментами и фишками. Без воды — только то, что реально упрощает работу.
👉 Делимся знаниями и аудиторией — растём вместе ⚡️ Забирай ПАПКУ бесплатно. * Отписаться можно в любой момент. Остаться — тоже. ✔️
Не выпадай из обоймы - будь всегда на острие ! 📌
🔥1
4828. Через полгода заказчик просит удалить функцию «печать отчёта». После удаления ломается другой модуль. Чего не хватало с самого начала?
Anonymous Quiz
15%
Детальной API-спецификации
76%
Матрицы трассируемости требований (RTM)
0%
Еженедельных созвонов с заказчиком
9%
Логирования всех вызовов функций
В больших системах требования редко живут изолированно. Функция «печать отчёта» может использоваться в других модулях: например, отчёт может быть вложением в email, данными для экспорта в Excel, основой для графика. Удаляя её, разработчик должен знать обо всех связях.
Что такое RTM?
Это таблица, где строки — требования, столбцы — компоненты системы (тест-кейсы, модули кода, UI-экраны). На пересечении отмечается связь. Когда требование меняется или удаляется, аналитик сразу видит, какие артефакты нужно проверить.
Реальный кейс: В CRM при удалении поля «регион» из формы клиента перестала работать валидация адреса в модуле доставки — разработчик не знал о связи. RTM выявила бы её за минуту.
Вывод: RTM — не бюрократия, а инструмент контроля изменений. Аналитик обязан поддерживать её хотя бы в простом виде (Excel, Jira связи).
Please open Telegram to view this post
VIEW IN TELEGRAM
📂 Подборка каналов по ИИ и IT технологиям
Подборка каналов для тех, кто интересуется AI, работает в IT сфере и хочет расширить свой кругозор без необходимости мониторить сотни источников самому, а также сделать качественный АПГРЕЙД своих ИИ инструментов.
Что внутри:
🔗 [Добавить папку]
Подборка каналов для тех, кто интересуется AI, работает в IT сфере и хочет расширить свой кругозор без необходимости мониторить сотни источников самому, а также сделать качественный АПГРЕЙД своих ИИ инструментов.
Что внутри:
– AI: реальные инструменты и внедрения, без хайпа;
– IT технологии: тренды, обзоры, инсайты от первых лиц;
– Карьера: как расти и не выгорать;
– HR Tech: кто и как нанимает профессионалов сейчас;
– AI life hacks: применение ИИ для тех, кто находиться за границей и ищет там удаленную работу.
🔗 [Добавить папку]
🔥1
4829. При тестировании оплаты проверили успех, неверный CVV, истекшую карту — всё ок. После релиза хакеры подменили сумму в запросе с 1000 на 1. Какого теста не хватало?
Anonymous Quiz
0%
Тестирования производительности
95%
Тестирования безопасности на уровне API (подмена параметров)
4%
Юзабилити-тестирования
1%
Тестирования совместимости браузеров
Хакер перехватывает запрос к API и меняет поле
amountПочему стандартные тесты не ловят?
Обычно тестируют интерфейс: в поле ввода 1 → ошибка. Но API-запрос можно сформировать вручную (Postman, curl) и отправить любые параметры.
Какой тест нужен?
Parameter tampering — часть тестирования безопасности API. Тестировщик должен проверить:
Не передаётся ли критическая величина (сумма, скидка, количество) из ненадёжного источника?
Пересчитывает ли сервер сумму по внутренним данным (цена из БД, количество из корзины)?
Реальный кейс: Убытки одного магазина после такой атаки составили $50 000 за ночь.
Вывод: В требованиях к интеграции нужно явно писать: «Сервер не доверяет значениям суммы, скидки, статуса, переданным клиентом».
Please open Telegram to view this post
VIEW IN TELEGRAM
4830. В Kafka для заказов настроен ключ = order_id, партиций = 3. При отключении брокера порядок сообщений нарушается. Какой параметр не учли?
Anonymous Quiz
9%
acks=all
71%
min.insync.replicas и acks=all
5%
Слишком много партиций
15%
Продюсер не ждёт подтверждения