👍1🔥1
Как системный аналитик может улучшить процесс тестирования: от требований до автоматизации
"На первый взгляд предназначение каждой роли очевидно: аналитик закладывает почву, собирает требования, формулирует бизнес-логику, продумывает сценарии, тестировщик, в свою очередь, проверяет, работает ли всё так, как задумано. Аналитик не должен писать тест-кейсы за QA, выбирать инструменты автоматизации или решать, что проверять первым. Но кое-что он всё-таки может сделать, чтобы облегчить тестирование и помочь команде достичь итоговую цель проекта."
Читать статью
"На первый взгляд предназначение каждой роли очевидно: аналитик закладывает почву, собирает требования, формулирует бизнес-логику, продумывает сценарии, тестировщик, в свою очередь, проверяет, работает ли всё так, как задумано. Аналитик не должен писать тест-кейсы за QA, выбирать инструменты автоматизации или решать, что проверять первым. Но кое-что он всё-таки может сделать, чтобы облегчить тестирование и помочь команде достичь итоговую цель проекта."
Читать статью
вАЙТИ
Как системный аналитик может улучшить процесс тестирования: от требований до автоматизации
DIY-медиа для ИТ-специалистов. Практические истории про решение самых разных задач из ИТ и смежных областей.
❤2👍1
📑 Брокеры сообщений Kafka и RabbitMQ в реальной жизни
Автор - Александр Борецкий, архитектор в Т1 Облако:
"Поделюсь своим опытом работы с самыми популярными из брокеров сообщений — Kafka и RabbitMQ. Расскажу, как выбрать и настроить подходящий брокер, а также какие архитектурные особенности есть у каждого из них."
Читать статью
Автор - Александр Борецкий, архитектор в Т1 Облако:
"Поделюсь своим опытом работы с самыми популярными из брокеров сообщений — Kafka и RabbitMQ. Расскажу, как выбрать и настроить подходящий брокер, а также какие архитектурные особенности есть у каждого из них."
Читать статью
👍2
Сегодня поговорим о том, как жизненный цикл программного обеспечения (SDLC) влияет на нашу работу и какие задачи мы решаем на каждом этапе.
SDLC – это структурированный процесс, описывающий все этапы разработки ПО от идеи до поддержки готового продукта. И аналитик – ключевой игрок на каждом из них!
▫️Планирование: Помогаем определить цели проекта, собираем предварительную информацию о потребностях бизнеса.
Пример: Участвуем в совещаниях по определению scope проекта, изучаем бизнес-планы.
▫️Анализ: Собираем и анализируем требования, определяем функциональность системы. Это наша основная зона ответственности!
Пример: Проводим интервью со стейкхолдерами, документируем пользовательские истории, строим Use Case диаграммы.
▫️Проектирование: Участвуем в проектировании пользовательского интерфейса, обеспечиваем соответствие архитектуры будущей системы собранным требованиям.
Пример: Работаем вместе с UX/UI дизайнерами, проверяем макеты на соответствие User Stories, создаем прототипы.
▫️Разработка: Поддерживаем команду разработчиков, отвечаем на возникающие вопросы, уточняем требования.
Пример: Регулярно участвуем в стендапах, консультируем разработчиков по сложным бизнес-правилам.
▫️Тестирование: Участвуем в разработке тестовых сценариев, проверяем соответствие реализованной функциональности требованиям.
▫️Внедрение: Подготавливаем документацию, участвуем в обучении пользователей, помогаем решать проблемы, возникающие при внедрении.
Пример: Создаем руководства пользователя, участвуем в демонстрациях нового функционала, собираем обратную связь..
▫️Сопровождение: Собираем обратную связь от пользователей, анализируем проблемы, участвуем в разработке обновлений и исправлений.
Пример: Ведем журнал ошибок, анализируем отчеты пользователей о проблемах, участвуем в планировании следующих итераций.
Получается, что аналитик – это связующее звено между бизнесом и разработкой на каждом этапе!
Для тех, кто хочет чуть больше погрузиться в тему SDLC подготовили подборку статей:
🖇 SDLC: о жизненном цикле разработки ПО
🖇 Этапы жизненного цикла разработки ПО или что такое SDLC?
🖇 База про жизненный цикл разработки ПО (SDLC): этапы, виды моделей и их различия
🖇 Что такое жизненный цикл разработки программного обеспечения?
🖇 Бизнес-аналитик в ИТ: SLDC, Agile, модели и методологии разработки ПО
🖇 Путь аналитика. Работа над ошибками
🖇 What is the software development life cycle (SDLC)?
🖇 What is the SDLC?
SDLC – это структурированный процесс, описывающий все этапы разработки ПО от идеи до поддержки готового продукта. И аналитик – ключевой игрок на каждом из них!
▫️Планирование: Помогаем определить цели проекта, собираем предварительную информацию о потребностях бизнеса.
Пример: Участвуем в совещаниях по определению scope проекта, изучаем бизнес-планы.
▫️Анализ: Собираем и анализируем требования, определяем функциональность системы. Это наша основная зона ответственности!
Пример: Проводим интервью со стейкхолдерами, документируем пользовательские истории, строим Use Case диаграммы.
▫️Проектирование: Участвуем в проектировании пользовательского интерфейса, обеспечиваем соответствие архитектуры будущей системы собранным требованиям.
Пример: Работаем вместе с UX/UI дизайнерами, проверяем макеты на соответствие User Stories, создаем прототипы.
▫️Разработка: Поддерживаем команду разработчиков, отвечаем на возникающие вопросы, уточняем требования.
Пример: Регулярно участвуем в стендапах, консультируем разработчиков по сложным бизнес-правилам.
▫️Тестирование: Участвуем в разработке тестовых сценариев, проверяем соответствие реализованной функциональности требованиям.
▫️Внедрение: Подготавливаем документацию, участвуем в обучении пользователей, помогаем решать проблемы, возникающие при внедрении.
Пример: Создаем руководства пользователя, участвуем в демонстрациях нового функционала, собираем обратную связь..
▫️Сопровождение: Собираем обратную связь от пользователей, анализируем проблемы, участвуем в разработке обновлений и исправлений.
Пример: Ведем журнал ошибок, анализируем отчеты пользователей о проблемах, участвуем в планировании следующих итераций.
Получается, что аналитик – это связующее звено между бизнесом и разработкой на каждом этапе!
Для тех, кто хочет чуть больше погрузиться в тему SDLC подготовили подборку статей:
🖇 SDLC: о жизненном цикле разработки ПО
🖇 Этапы жизненного цикла разработки ПО или что такое SDLC?
🖇 База про жизненный цикл разработки ПО (SDLC): этапы, виды моделей и их различия
🖇 Что такое жизненный цикл разработки программного обеспечения?
🖇 Бизнес-аналитик в ИТ: SLDC, Agile, модели и методологии разработки ПО
🖇 Путь аналитика. Работа над ошибками
🖇 What is the software development life cycle (SDLC)?
🖇 What is the SDLC?
❤1👍1
Монолитная и микросервисная архитектура. Сравнение
В статье поговорим об отличиях микросервисной архитектуры от монолитной и разберемся, что лучше подойдет для вашего следующего проекта.
Выбор правильной архитектуры приложения – залог его успеха в будущем. К счастью для вас, в данной статье мы сравним два популярных и крайне действенных подхода – монолитную и микросервисную архитектуру.
Далее мы обсудим сильные и слабые стороны каждой архитектуры. А после прочтения статьи вы будете четко понимать, когда и что лучше выбрать.
Итак, будь вы опытным архитектором или любознательным разработчиком, давайте поговорим об отличиях монолитов от микросервисов, чтобы вы могли выбрать свое идеальное решение для следующего проекта!
Читать статью
В статье поговорим об отличиях микросервисной архитектуры от монолитной и разберемся, что лучше подойдет для вашего следующего проекта.
Выбор правильной архитектуры приложения – залог его успеха в будущем. К счастью для вас, в данной статье мы сравним два популярных и крайне действенных подхода – монолитную и микросервисную архитектуру.
Далее мы обсудим сильные и слабые стороны каждой архитектуры. А после прочтения статьи вы будете четко понимать, когда и что лучше выбрать.
Итак, будь вы опытным архитектором или любознательным разработчиком, давайте поговорим об отличиях монолитов от микросервисов, чтобы вы могли выбрать свое идеальное решение для следующего проекта!
Читать статью
Когда ТЗ — не боль, а удовольствие: Use Case
Автор - Ирина Пономарчук,
Бизнес-аналитик в Okko:
"На работе каждый день я описываю Use Case. Эта техника помогает увидеть путь пользователя от А до Я и не забыть про корнер-кейсы.
За 6 лет и 4 места работы я попробовала разные форматы и шаблоны описания юзкейсов. И недавно пообещала написать статью с примерами и картинками. Значит, поехали."
Читать статью
Автор - Ирина Пономарчук,
Бизнес-аналитик в Okko:
"На работе каждый день я описываю Use Case. Эта техника помогает увидеть путь пользователя от А до Я и не забыть про корнер-кейсы.
За 6 лет и 4 места работы я попробовала разные форматы и шаблоны описания юзкейсов. И недавно пообещала написать статью с примерами и картинками. Значит, поехали."
Читать статью
Хабр
Когда ТЗ — не боль, а удовольствие: Use Case
Пример юзкейса, который точно прочитают разработчики. Хабр, привет! Я Ира, бизнес-аналитик в онлайн-кинотеатре Okko . На работе каждый день я описываю Use Case. Эта техника помогает увидеть путь...
❤2👍1
Обзор и рецензия на книгу «Антихрупкость в IT»
Рецензия на книгу «Антихрупкость в IT», которая рассказывает о применении принципов антихрупкости, рассказанных Нассимом Талебом в его известной одно менной книге
Читать
Рецензия на книгу «Антихрупкость в IT», которая рассказывает о применении принципов антихрупкости, рассказанных Нассимом Талебом в его известной одно менной книге
Читать
Хабр
Обзор и рецензия на книгу «Антихрупкость в IT»
Мне всегда была интересна тема антихрупкости и работы Нассима Талеба — особенно в контексте их применения в IT. Книга « Антихрупкость в IT » попала в мой список рекомендаций больше года...
❤1👍1
Подборка полезных ссылок про System Design, синхронное и асинхронное взаимодействие, балансировку нагрузок :
- System Design для начинающих: всё, что вам нужно. Часть 1
- System Design для начинающих: всё, что вам нужно. Часть 2
- System Design для самых маленьких. Reference к интервью
- System Design 101
- System Design. Общие принцип прохождения интервью по проектированию ИТ-систем
- Интеграция: синхронное, асинхронное и реактивное взаимодействие, консистентность и транзакции
- Синхронное vs. Асинхронное: выбираем подход к взаимодействию микросервисов
- Асинхронная интеграция. Что это такое и как её дружить
- Достижение высокой пропускной способности без усугубления задержки
- Балансировка нагрузки: основные алгоритмы и методы
- System Design для начинающих: всё, что вам нужно. Часть 1
- System Design для начинающих: всё, что вам нужно. Часть 2
- System Design для самых маленьких. Reference к интервью
- System Design 101
- System Design. Общие принцип прохождения интервью по проектированию ИТ-систем
- Интеграция: синхронное, асинхронное и реактивное взаимодействие, консистентность и транзакции
- Синхронное vs. Асинхронное: выбираем подход к взаимодействию микросервисов
- Асинхронная интеграция. Что это такое и как её дружить
- Достижение высокой пропускной способности без усугубления задержки
- Балансировка нагрузки: основные алгоритмы и методы
👍3❤1
Краткий гайд по написанию бизнес-процессов
С чего начать?
1. Определите цель описания бизнес-процесса:
- Для обучения/инструкций: процесс должен быть простым и понятным для новичков.
- Для регламентов: процесс должен быть детализированным и формализованным.
- Для аудита: процесс должен отражать реальное положение дел, включая слабые места.
- Для автоматизации: процесс должен быть четким, с указанием точек интеграции и данных.
2. Соберите информацию:
- Поговорите с участниками процесса (сотрудниками, руководителями).
- Изучите документацию, если она есть. Или поищите инфу в инете.
- Наблюдайте за процессом в действии.
3. Определите границы процесса:
- Где процесс начинается?
- Где заканчивается?
- Какие входные и выходные данные?
- Кто ответственный или кто участник?
4. Выберите нотацию для описания:
- BPMN (Business Process Model and Notation) — для сложных процессов.
- Flowchart (блок-схемы) — для простых процессов.
- Текстовое описание — для инструкций или регламентов.
Как правильно описывать бизнес-процессы?
1. Разбейте процесс на этапы:
- Каждый этап должен быть логически завершенным.
- Укажите, кто отвечает за каждый этап (роль или должность).
2. Используйте четкие формулировки:
- Избегайте двусмысленности.
- Указывайте конкретные действия, например, "Сотрудник проверяет заявку на соответствие требованиям".
3. Добавьте условия и ветвления:
- Если процесс может идти по разным сценариям, укажите условия (например, "Если заявка одобрена, перейти к этапу 3; если нет, вернуть на доработку").
4. Укажите входы и выходы:
- Что поступает на вход этапа (документы, данные, ресурсы).
- Что является результатом этапа.
5. Визуализируйте процесс:
- Используйте диаграммы, схемы, таблицы для наглядности.
- Для сложных процессов используйте специализированные инструменты (например, Bizagi, Lucidchart, Visio).
Советы для новичков
- Начинайте с простого:
Не пытайтесь описать весь процесс сразу. Разбейте его на части.
- Не усложняйте:
Избегайте излишней детализации, если это не требуется для цели.
- Проверяйте на практике: Убедитесь, что описание соответствует реальности.
- Используйте шаблоны:
Найдите примеры похожих процессов и адаптируйте их под свои нужды.
- Собирайте обратную связь:
Покажите описание участникам процесса и внесите правки.
Инструменты для описания бизнес-процессов
- BPMN-диаграммы: Bizagi, Lucidchart, Visio.
- Блок-схемы: Draw.io, Miro.
- Текстовые редакторы: Word, Google Docs (для регламентов).
- Специализированные программы: ARIS, ELMA, Business Studio.
Пример структуры описания бизнес-процесса (можно использовать как шаблон)
1. Название процесса:
Например, "Обработка заказа клиента"
2. Цель процесса:
Например, "Обеспечить своевременную обработку и доставку заказа"
3. Участники процесса:
Менеджер, склад, курьер
4. Этапы процесса:
- Этап 1: Получение заказа.
- Этап 2: Проверка наличия товара.
- Этап 3: Сборка заказа.
- Этап 4: Доставка клиенту
5. Входы/выходы:
Заявка клиента → Подтверждение заказа → Доставленный товар
6. Условия и исключения:
Если товара нет на складе, уведомить клиента.
С чего начать?
1. Определите цель описания бизнес-процесса:
- Для обучения/инструкций: процесс должен быть простым и понятным для новичков.
- Для регламентов: процесс должен быть детализированным и формализованным.
- Для аудита: процесс должен отражать реальное положение дел, включая слабые места.
- Для автоматизации: процесс должен быть четким, с указанием точек интеграции и данных.
2. Соберите информацию:
- Поговорите с участниками процесса (сотрудниками, руководителями).
- Изучите документацию, если она есть. Или поищите инфу в инете.
- Наблюдайте за процессом в действии.
3. Определите границы процесса:
- Где процесс начинается?
- Где заканчивается?
- Какие входные и выходные данные?
- Кто ответственный или кто участник?
4. Выберите нотацию для описания:
- BPMN (Business Process Model and Notation) — для сложных процессов.
- Flowchart (блок-схемы) — для простых процессов.
- Текстовое описание — для инструкций или регламентов.
Как правильно описывать бизнес-процессы?
1. Разбейте процесс на этапы:
- Каждый этап должен быть логически завершенным.
- Укажите, кто отвечает за каждый этап (роль или должность).
2. Используйте четкие формулировки:
- Избегайте двусмысленности.
- Указывайте конкретные действия, например, "Сотрудник проверяет заявку на соответствие требованиям".
3. Добавьте условия и ветвления:
- Если процесс может идти по разным сценариям, укажите условия (например, "Если заявка одобрена, перейти к этапу 3; если нет, вернуть на доработку").
4. Укажите входы и выходы:
- Что поступает на вход этапа (документы, данные, ресурсы).
- Что является результатом этапа.
5. Визуализируйте процесс:
- Используйте диаграммы, схемы, таблицы для наглядности.
- Для сложных процессов используйте специализированные инструменты (например, Bizagi, Lucidchart, Visio).
Советы для новичков
- Начинайте с простого:
Не пытайтесь описать весь процесс сразу. Разбейте его на части.
- Не усложняйте:
Избегайте излишней детализации, если это не требуется для цели.
- Проверяйте на практике: Убедитесь, что описание соответствует реальности.
- Используйте шаблоны:
Найдите примеры похожих процессов и адаптируйте их под свои нужды.
- Собирайте обратную связь:
Покажите описание участникам процесса и внесите правки.
Инструменты для описания бизнес-процессов
- BPMN-диаграммы: Bizagi, Lucidchart, Visio.
- Блок-схемы: Draw.io, Miro.
- Текстовые редакторы: Word, Google Docs (для регламентов).
- Специализированные программы: ARIS, ELMA, Business Studio.
Пример структуры описания бизнес-процесса (можно использовать как шаблон)
1. Название процесса:
Например, "Обработка заказа клиента"
2. Цель процесса:
Например, "Обеспечить своевременную обработку и доставку заказа"
3. Участники процесса:
Менеджер, склад, курьер
4. Этапы процесса:
- Этап 1: Получение заказа.
- Этап 2: Проверка наличия товара.
- Этап 3: Сборка заказа.
- Этап 4: Доставка клиенту
5. Входы/выходы:
Заявка клиента → Подтверждение заказа → Доставленный товар
6. Условия и исключения:
Если товара нет на складе, уведомить клиента.
👍3
Архитектурные практики в «кровавом энтерпрайзе»: данные, управление сложными системами и влияние AI
⏳ 11 мин
Перейти
⏳ 11 мин
Перейти
Архитектура платежных систем
Термины
🔹платежная система — инфраструктура для маршрутизации платежей, безопасности операций и расчетов между банками (Мир, Visa, MasterCard)
🔹эквайер — банк/финансовая организация, обслуживает терминалы и принимает платежи от клиентов
🔹процессинговый центр (ПЦ) — система для обработки платежных запросов, передает их в платежную систему и банк-эмитент
🔹банк-эмитент — банк,который выпустил карту клиента; он проверяет баланс, авторизует платеж и списывает средства
Рассмотрим обобщенно: как происходит платеж с момента поднесения карты к терминалу эквайринга до списания средств со счета
1️⃣ Поднесение карты к терминалу эквайринга
Карту подносят к терминалу. Начинается процесс авторизации платежа
Терминал может быть:
🔵физическим (например, POS-терминал в магазине)
🔵виртуальным (веб-форма на сайте, мобильное приложение)
Платежная система (например, «Мир») определяет стандарты передачи данных (например, MIR Accept) и их безопасность
2️⃣ Передача данных с терминала эквайринга
Карта успешно считана, терминал передает платежные данные (номер карты, срок действия, CVV, сумму транзакции) в ПЦ эквайера через защищенное соединение
3️⃣ Передача данных в ПЦ и платежную систему
ПЦ эквайера принимает платежный запрос, проверяет его корректность и передает в платежную систему (например, «Мир»)
Платежная система маршрутизирует платеж:
🔵определет банк-эмитент по номеру карты (BIN)
🔵отправляет ему запрос на авторизацию
4️⃣ Проверка данных и авторизация в банке-эмитенте
Банк-эмитент проверяет:
🔵достаточно ли средств на счете
🔵корректно введенны данные
🔵антифрод-проверки
🔵есть ли блокировки на карте и т.д.
Если все ок, банк-эмитент выдает авторизацию и передает ответ (одобрение/отказ в проведении транзакции) платежной системе
Платежная система передает его в ПЦ эквайера - > эквайрер передает результат на терминал
5️⃣ Завершение транзакции и списание средств
После авторизации банк-эмитент резервирует сумму на счете покупателя
ПЦ передает подтверждение эквайеру
Эквайер передает его продавцу -> продавец получает платеж, транзакция завершается
Платежная система участвует в клиринге* и окончательных расчетах между банком-эквайером и банком-эмитентом
клиринг — процесс взаимных расчетов между банками, выполняется платежной системой
Примеры технологий на каждом этапе
Поднесение карты к терминалу эквайринга
⚪️NFC (Near Field Communication) — для передачи данных между картой и терминалом (в том числе для Apple Pay, Google Pay). Работает на основе RFID и требует наличия чипа в карте
⚪️RFID (Radio Frequency Identification) — передача данных между картой (тегом) и терминалом через радиоволны
⚪️EMV (Europay, MasterCard, Visa) — стандарт для карт с чипом с криптографическими алгоритмами защиты данных.
⚪️MIR Accept — аналогичный стандарт для платежной системы «Мир», дополненный механизмами защиты + адаптация к требованиям
Передача данных с терминала эквайринга
⚪️TLS (Transport Layer Security) — защищенный протокол передачи данных
⚪️API (REST, SOAP) — для интеграции с процессингом и банками-эквайерами
Передача данных в ПЦ и платежную систему
⚪️API
⚪️Очереди сообщений (Kafka, RabbitMQ) — для асинхронной обработки платежных запросов
Проверка данных и авторизация в банке-эмитенте
⚪️API
⚪️OAuth 2.0 — механизм аутентификации и авторизации между сервисами
⚪️Системы антифрода (например, машинное обучение)
Термины
🔹платежная система — инфраструктура для маршрутизации платежей, безопасности операций и расчетов между банками (Мир, Visa, MasterCard)
🔹эквайер — банк/финансовая организация, обслуживает терминалы и принимает платежи от клиентов
🔹процессинговый центр (ПЦ) — система для обработки платежных запросов, передает их в платежную систему и банк-эмитент
🔹банк-эмитент — банк,который выпустил карту клиента; он проверяет баланс, авторизует платеж и списывает средства
Рассмотрим обобщенно: как происходит платеж с момента поднесения карты к терминалу эквайринга до списания средств со счета
1️⃣ Поднесение карты к терминалу эквайринга
Карту подносят к терминалу. Начинается процесс авторизации платежа
Терминал может быть:
🔵физическим (например, POS-терминал в магазине)
🔵виртуальным (веб-форма на сайте, мобильное приложение)
Платежная система (например, «Мир») определяет стандарты передачи данных (например, MIR Accept) и их безопасность
2️⃣ Передача данных с терминала эквайринга
Карта успешно считана, терминал передает платежные данные (номер карты, срок действия, CVV, сумму транзакции) в ПЦ эквайера через защищенное соединение
3️⃣ Передача данных в ПЦ и платежную систему
ПЦ эквайера принимает платежный запрос, проверяет его корректность и передает в платежную систему (например, «Мир»)
Платежная система маршрутизирует платеж:
🔵определет банк-эмитент по номеру карты (BIN)
🔵отправляет ему запрос на авторизацию
4️⃣ Проверка данных и авторизация в банке-эмитенте
Банк-эмитент проверяет:
🔵достаточно ли средств на счете
🔵корректно введенны данные
🔵антифрод-проверки
🔵есть ли блокировки на карте и т.д.
Если все ок, банк-эмитент выдает авторизацию и передает ответ (одобрение/отказ в проведении транзакции) платежной системе
Платежная система передает его в ПЦ эквайера - > эквайрер передает результат на терминал
5️⃣ Завершение транзакции и списание средств
После авторизации банк-эмитент резервирует сумму на счете покупателя
ПЦ передает подтверждение эквайеру
Эквайер передает его продавцу -> продавец получает платеж, транзакция завершается
Платежная система участвует в клиринге* и окончательных расчетах между банком-эквайером и банком-эмитентом
клиринг — процесс взаимных расчетов между банками, выполняется платежной системой
Примеры технологий на каждом этапе
Поднесение карты к терминалу эквайринга
⚪️NFC (Near Field Communication) — для передачи данных между картой и терминалом (в том числе для Apple Pay, Google Pay). Работает на основе RFID и требует наличия чипа в карте
⚪️RFID (Radio Frequency Identification) — передача данных между картой (тегом) и терминалом через радиоволны
⚪️EMV (Europay, MasterCard, Visa) — стандарт для карт с чипом с криптографическими алгоритмами защиты данных.
⚪️MIR Accept — аналогичный стандарт для платежной системы «Мир», дополненный механизмами защиты + адаптация к требованиям
Передача данных с терминала эквайринга
⚪️TLS (Transport Layer Security) — защищенный протокол передачи данных
⚪️API (REST, SOAP) — для интеграции с процессингом и банками-эквайерами
Передача данных в ПЦ и платежную систему
⚪️API
⚪️Очереди сообщений (Kafka, RabbitMQ) — для асинхронной обработки платежных запросов
Проверка данных и авторизация в банке-эмитенте
⚪️API
⚪️OAuth 2.0 — механизм аутентификации и авторизации между сервисами
⚪️Системы антифрода (например, машинное обучение)
👍2❤1
Идеальных систем не существует. Монолит, микросервисы и цена распределённости. CAP, ACID, BASE
Время чтения: 13 мин
Читать статью
Время чтения: 13 мин
Читать статью
👍1