**400к! Реальное собеседование системного аналитика в IGAMING — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/400k-real-system-analyst-interview-igaming/

Системная аналитик делится опытом 5+ лет в Сбере и X5: UML, BPMN, C4, интеграции (REST, SOAP, Kafka, WebSocket), синхронное и асинхронное взаимодействие на реальном собеседовании в iGaming.

## Key Takeaways

- Кандидат обладает широким практическим опытом в интеграциях, нотациях и архитектуре.
- Разница синхронного и асинхронного взаимодействия заключается в наличии или отсутствии ожидания ответа.
- Архитектурные решения принимаются коллегиально: аналитик готовит предложения, тех-лид и комитет согласовывают.

## What the video covers

- Кандидат — системный аналитик с опытом более 5 лет, работала в Сбербанке и X5 Retail Group с микросервисными и монолитными архитектурами.
- Базы данных: реляционные (Teradata в Сбере, PostgreSQL в остальных проектах) и нереляционные.
- Интеграции: раньше в Сбере использовался SOAP, затем REST; также JSON-RPC внутри микросервисов, WebSocket, WebHooks, SSE и Kafka как брокер сообщений.
- Нотации: UML (sequence-диаграммы для интеграций и use case), BPMN для бизнес-процессов (в X5 процессы исполнялись на Camunda), C4 для архитектуры без Structurizer.
- Процесс принятия архитектурных решений: на прошлом проекте был отдельный архитектор, на текущем решения согласовываются с тех-лидом и архитектурным комитетом.
- Разбор темы синхронного и асинхронного взаимодействия: синхронное предполагает ожидание ответа, асинхронное позволяет продолжать работу параллельно.
- Обсуждение видов интеграций: клиент-сервер (запрос-ответ), общая база данных, брокеры сообщений (Kafka, RabbitMQ, IBM MQ, ActiveMQ), событийная архитектура.
- Сравнение HTTP/1.x и HTTP/2: бинарный формат, мультиплексирование, двунаправленное соединение, сжатие заголовков.
- Обсуждение передачи параметров в GET/PUT/PATCH запросах и выбора способа передачи массивов данных в query-параметрах.

## Chapters

1. 00:00 Представление опыта кандидата
2. 02:15 Нотации: UML, BPMN, C4
3. 04:00 Процесс принятия архитектурных решений
4. 05:59 Синхронное и асинхронное взаимодействие
5. 07:53 Брокеры сообщений и виды интеграций
6. 11:21 Протоколы HTTP/1.x и HTTP/2
7. 15:21 Передача параметров в REST-запросах

Answers

## Questions about this video

Какой опыт в системном анализе заявляет кандидат?

Более 5 лет опыта на проектах Сбербанка и X5 Retail Group, работа с микросервисными и монолитными архитектурами, реляционными и нереляционными БД.

В чём разница между синхронным и асинхронным взаимодействием?

При синхронном взаимодействии клиент ждёт ответа от сервера, соединение остаётся открытым. При асинхронном клиент продолжает работу, а ответ может не прийти или прийти позже.

Какие нотации использует кандидат для проектирования?

UML (sequence-диаграммы для интеграций), BPMN для бизнес-процессов (в X5 — исполняемые процессы на Camunda) и C4 для архитектурных диаграмм.

## Full Transcript — Download SRT & Markdown

00:00

Speaker A

О себе немного расскажу. Про свой релевантный опыт в системном анализе — более 5 лет. Работала на крупнейших проектах Сбербанка и Тех X5 Retail Group по стеку. А работала с видами архитектур: микросервисная, монолитная, переход с монолита на микросервисы.

00:20

Speaker A

По базам данным, работала с реляционными теродата в Сбери, постгры на всех остальных проектах. из нереляционных.

00:28

Speaker A

По базам данных работала с реляционными — Teradata в Сбере, Postgres на всех остальных проектах. Из нереляционных — Dis. Сейчас его активно используем. Расскажу, если нужно будет, по каким задачам.

00:34

Speaker A

По интеграциям, а, которые тоже использовала за всё время. А в Сбере там 5 лет назад у нас был только SUAP, потом уже на всех проектах это был рест.

00:47

Speaker A

По интеграциям, которые тоже использовала за всё время: в Сбере пять лет назад у нас был только SOAP, потом уже на всех проектах это был REST.

01:11

Speaker A

JRPC фреймворку. Здесь уже так по интеграциям, по нотациям. Что осталось? Использую активно UML. Измейлев использую sequнс для описания взаимодействия систем при интеграции, при различных юзкейсах, где помогает и с бизнес-нотации использую BPMN, так как бизнес-аналитики у нас не особо их

01:35

Speaker A

Ну и за последние два проекта — плюс WebSockets и WebHooks, асинхронные способы интеграции, также Kafka на предыдущих трёх проектах как очередь сообщений. А SSE тоже используем сейчас для отправки уведомлений с сервера клиенту. А JSON-RPC внутри микросервисной архитектуры — сервисы между собой взаимодействуют по JSON-RPC фреймворку. Здесь уже так по интеграциям, по нотациям.

01:57

Speaker A

бизнес-процессы, запускали их там на стенды и прогоняли уже. По архитектуре использую C4 сейчас, так как один из проектов у меня в лидировании, то здесь архитектуру отрисовываю именно в C4, но без структурайзера. пару раз пробовала в нём, но вдруё просто быстрее накинуть и

02:15

Speaker A

Что осталось? Использую активно UML. Из UML использую sequence для описания взаимодействия систем при интеграции, при различных use case, где помогает. А из бизнес-нотаций использую BPMN, так как бизнес-аналитики у нас не особо их отрисовывают, но для понимания бизнес-процесса сама связываюсь с бизнес-аналитиками и прорисовываю. А по BPMN был большой опыт в X5 IL, где мы как системные аналитики делали процессы исполняемыми, то есть на Camunda, под ней там Java-движок, и мы через JavaScript делали, а бизнес-процессы запускали их там на стенды и прогоняли уже. По архитектуре использую C4 сейчас, так как один из проектов у меня в лидировании, то здесь архитектуру отрисовываю именно в C4, но без Structurizer. Пару раз пробовала в нём, но вдруг просто быстрее накидать и уже показать, как у нас будет взаимодействие происходить. Вот. Готовы ответить дальше на вопросы? Спасибо. Чётко, тезисно, всё понятно.

02:27

Speaker A

А, но у меня есть пару вопросиков, а именно по архитектурным решениям. То есть как вы устроим процесс принятия их?

02:35

Speaker A

А, но у меня есть пару вопросиков, а именно по архитектурным решениям. То есть как вы устроили процесс принятия их?

02:45

Speaker A

Давай я расскажу на текущем проекте и на прошлом, чтобы потому что разница большая, чтобы было понимание, как и так, и так работало. На предыдущем проекте ВНОТЕХИ у нас был свой архитектор, где непосредственно он принимал решение, но системные аналитики

02:58

Speaker A

Там приходит архитектор, говорит: "Делаем так". Или ты можешь спокойно, у тебя есть свободная эта воля, прийти и написать решение своё, пойти и согласовать его с архитектором?

03:17

Speaker A

защищает, ну вот именно техническую, потому что тех, какую-то часть защищаю я, которую предлагаю по своей задаче.

03:26

Speaker A

Давай я расскажу на текущем проекте и на прошлом, потому что разница большая, чтобы было понимание, как работало и так, и так. На предыдущем проекте во ВНОТЕХИ у нас был свой архитектор, который непосредственно принимал решение, но системные аналитики были в очень тесном взаимодействии с архитектором. Мы готовили вместе артефакты уровня решений, архитектуры решений. А здесь же у нас сейчас нет архитектора, и проект мы развиваем с нуля, поэтому мы с тех-лидом вместе рисуем архитектуру, вместе ходим на синк, а какую-то её часть защищает он, ну вот именно техническую, потому что техническую часть защищаю я, которую предлагаю по своей задаче.

03:42

Speaker A

Хорошо. Э, у меня, наверное, по вопросам всё. Предлагаю перейти к нашей техчасти. И первым делом, первым топиком у нас будет, наверное, разговор про описку. Но сначала давай вот так абстрактно поговорим. Вот у нас есть система А, есть система B. Ну, сервис А, сервис B.

03:59

Speaker A

Вот вместе согласовываем, вместе обсуждаем, вместе договариваемся, как будем делать. Ну, потом уже архитектурный комитет принимает решение: делаем так, либо не делаем, либо что-то поправить. Ну и, собственно, согласовываем решение и идём его описывать и разрабатывать.

04:15

Speaker A

два сервиса могут коннектиться к общей базе, получать данные через неё, где один, например, пишет, другой читает из этого сервиса. Ещё есть способ у нас асинхронный например да брокеры сообщений. А, ну, построена на событиях.

04:30

Speaker A

Хорошо. Э, у меня, наверное, по вопросам всё. Предлагаю перейти к нашей техчасти. И первым делом, первым топиком у нас будет, наверное, разговор про опишки. Но сначала давай вот так абстрактно поговорим. Вот у нас есть система А, есть система B. Ну, сервис А, сервис B. Какими способами мы можем доставить данные из одной точки в другую? То есть какие у нас могут быть способы интеграции?

04:43

Speaker A

Синхронном у нас подразумевается, что будет всегда ответ. Он должен быть, но понятно, что в случае ошибок, например, его быть не может. В асинхронном взаимодействии у нас может приходить ответ, но по идее эта технология нам не предполагает, что нам там откуда-то

05:03

Speaker A

У нас может быть, да, клиент-серверная архитектура, где один сервис выступает клиентом, другой сервером, запрос-ответ данных. Потом эти два сервиса могут коннектиться к общей базе, получать данные через неё, где один, например, пишет, другой читает. Ещё есть асинхронный способ, например, брокеры сообщений. А, ну, построенный на событиях — событийная архитектура. Здесь у нас один сервис, например, пишет, другой из него вычитывает.

05:21

Speaker A

это или я могу идти дальше полоте? Да, ты можешь идти дальше в асинхронном взаимодействии, то есть ты можешь дальше заниматься своей работой, обрабатывать другие запросы. То есть у тебя здесь работает, ну, как параллельная логика. А синхроном получается наоборот, что я бы

05:37

Speaker A

А давай поговорим поглубже. В чём отличие синхронного от асинхронного процесса? Почему их так разделяют?

05:52

Speaker A

что он там по тайм-ауту может упасть, но да, у тебя открывается соединение и ждёт, пока будет ответ от сервера.

05:58

Speaker A

Синхронно у нас подразумевается, что ответ будет всегда. Он должен быть, но понятно, что в случае ошибок его быть не может. В асинхронном взаимодействии у нас может приходить ответ, но по идее эта технология нам не предполагает, что откуда-то придёт ответ. Поэтому разница только в том, что ответ есть или нет.

06:15

Speaker A

Давай поговорим по технологиям. Есть же опишки и есть разные. Ну, это по факту приставка, постфикс, ну, не суть важно. И вот какие виды опишек в целом бывают. Ты уже ранее перечисляла, с какими работала. Давай повторно проговорим.

06:30

Speaker A

К примеру, если пойдём по бизнес-логике: мы что-то берём, получаем данные в запросе, я дальше вызываю какую-то API, и что происходит здесь? Я стою и жду, пока они получат это, или я могу идти дальше?

06:42

Speaker A

А брокер сообщения они относятся к копишкам. Ну да, в банке, например, мы относили, мы говорили, что там контракт кавка АИ, да, и мы понимали, что АИ - это интерфейс взаимодействия между веб-системами.

06:54

Speaker A

Да, ты можешь идти дальше. В асинхронном взаимодействии ты можешь продолжать свою работу, обрабатывать другие запросы. То есть здесь работает как бы параллельная логика. А в синхронном наоборот: я бы дождался ответа, пока не получу. Ты обращаешься с клиента на сервер, у тебя открывается TCP-соединение, и пока сервер не пришлёт ответ, твоё TCP-соединение будет стоять и ждать. Понятно, что по таймауту оно может упасть, но да, соединение открыто и ждёт ответа от сервера.

07:08

Speaker A

В чём их основные отличие? Какая разница? В чём основное отличие? В том, что, во-первых, они работают на разных версиях протокола HTTP. Rest он работает на HTTP 1 и1. JRPC он работает на версии HTTP 2.0.

07:26

Speaker A

Каких вендоров можешь назвать, к примеру, из брокеров?

07:34

Speaker A

HTP протокола создаётся вот это вот однонаправленный конект, где ты делаешь запрос и ждёшь. А в версии HTTP2.0 у тебя, во-первых, формат передачи данных уже бинарный. То есть не там не XML, ни Jon, ни файлы. Ты у тебя всё

07:53

Speaker A

Вендоров, например, Apache Kafka, Amazon... RabbitMQ, IBM MQ, ActiveMQ. Их на самом деле ещё много, но вот те, с которыми где-то хоть как-то сталкивалась, я перечислила.

08:15

Speaker A

и поэтому данные мы можем перегонять быстрее. Вообще HTTP2 разработал Facebook, если я не ошибаюсь, потому что по росту они передавали питабайты данных и начали терять какие-то биты данных и, ну, разработали вот вторую версию этого протокола и начали перегонять данные в

08:35

Speaker A

Давай поговорим по технологиям. Есть же опишки и есть разные — ну, это по факту приставка, постфикс, не суть важно. И вот какие виды опишек в целом бывают? Ты уже ранее перечисляла, с какими работала. Давай повторно проговорим.

08:42

Speaker A

Да, вот сейчас хотела договорить. А, спасибо большое, что вернул меня. Смотри, по росту что мы передаём. Мы передаём, а, jсоны XML, файлы, тексты, htмли. К примеру, JRPC мы создаём уже здесь такая типизация данных строгая.

08:59

Speaker A

Видопишек. Давай. REST, SOAP, GRPC, SSE, вебхуки, вебсокеты, а ну и брокеры сообщений.

09:17

Speaker A

на использование только протобафа или он может примерно там, не знаю, с XML там ссомн точно так же работать?

09:23

Speaker A

А брокеры сообщений относятся к опишкам?

09:29

Speaker A

Ну то есть получается JPC с Протобафом они писались вместе. JPC с протобафом писались вместе.

09:39

Speaker A

Ну да, в банке, например, мы относили — говорили, что там контракт Kafka API, и мы понимали, что API — это интерфейс взаимодействия между системами.

09:56

Speaker A

Если вот подойти к контексту, примеру, ну вот у нас обычно, да, REST он юзается везде. Ну, то есть на клиентсерверном, да, это архитектуре, то есть неважно, что здесь клиентом, это какой-то другой сервис, да, либо тут frontend клиент используется. А можем ли мы, к примеру,

10:14

Speaker A

Давай поговорим теперь про разные технологии среди опишек. Ты говорил, что работал и с JSON-RPC, и давай его попробуем сравнить с GRPC, к примеру. В чём их основные отличия? Какая разница?

10:27

Speaker A

Что это такое вообще? Что он из себя представляет? Прости, пожалуйста, контекстное что? Прорест. Прорест.

10:34

Speaker A

В чём основное отличие? В том, что, во-первых, они работают на разных версиях протокола HTTP. REST работает на HTTP 1.0 и 1.1. GRPC работает на версии HTTP 2.0.

10:46

Speaker A

Был разработан там в 2000ных годах в рамках аспиранторской работы. Вот что из себя представляет. Это напор правил, который нам а говорит о том, как можно использовать этот архитектурный стиль. То есть это не протокол, это не фреймворк, как мы

11:04

Speaker A

А в чём здесь разница между этими версиями?

11:16

Speaker A

Работает поверх HTTP, используя методы, ответы, а в зависимости там уже от методов у нас будет, не будет, например, тело запроса. Потом, а, каждый метод может относиться, ну, иметь некоторые свойства, да, там, по безопасности, а, эндопатентности кэшируемости.

11:33

Speaker A

В том, что в REST у тебя как раз-таки по HTTP 1.x создаётся однонаправленное соединение, где ты делаешь запрос и ждёшь. А в версии HTTP 2.0 у тебя, во-первых, формат передачи данных уже бинарный — не XML, не JSON, не файлы. Всё переходит в бинарный формат данных. Благодаря этому происходит мультиплексирование, ты можешь делать двунаправленное соединение, а потом сжатие заголовков. В общем, версия 2 славится тем, что у неё производительность выше, и поэтому данные мы можем перегонять быстрее. HTTP/2 разработал, если я не ошибаюсь, Facebook, потому что по HTTP они передавали петабайты данных и начали терять какие-то биты, и разработали вторую версию этого протокола и начали перегонять данные в бинарном виде.

11:42

Speaker A

Что такое шируемость? Мы можем говорить, что там, например, в целях производительности наш клиент, он может закашировать у себя данные с сервера, чтобы их переиспользовать. А, например, а мы понимаем, что какой-то какие-то данные у нас там обновляются раз, не

12:03

Speaker A

А на уровне формата обмена данными — что может использовать REST и что может использовать GRPC?

12:19

Speaker A

какой-то пользователь будет запрашивать эти данные, мы не будем их повторно дёргать с бэкэнда, тем самым не нагружать сервер. Мы их из нашего хранилища вернём и покажем нашему клиенту. А Restlik like, насколько я помню, оно мм ну как бы не

12:35

Speaker A

Да, вот это я как раз хотела договорить. Спасибо большое, что вернул меня. Смотри, по REST мы передаём JSON, XML, файлы, тексты, HTML. А GRPC — здесь уже строгая типизация данных. Нужно создать proto-схему, потому что данные будут передаваться через Protocol Buffers. Схема создаётся, и мы как аналитики её тоже описываем — что будет входить в эту схему, какие виды запросов будут отправляться и из чего будет состоять запрос.

12:46

Speaker A

Хорошо. Хорошо, давай провалимся тогда поглубже и поговорим на такие темы. Вотрес он на чём-то оперирует, и кто-то говорит функции, а кто-то говорит ресурсы. Давай попробуем определить, на чём оперирует всё-таки ст и как мы можем идентифицировать это.

13:07

Speaker A

GRPC строго ограничен использованием только Protobuf или он может, например, с XML работать так же?

13:16

Speaker A

Нет, на уровне кода мы не падаем. Просто вот представь, что я вот вижу курл, да?

13:21

Speaker A

Ну, то, что у него proto-схема должна быть обязательно, — это да, потому что без неё не

13:31

Speaker A

Угу. А, ну, когда мы видим мы видим с тобой ресурс Урал, по которому, значит, клиент обращается к серверу из урла. А при правильно спроектированном апе мы с тобой должны явно понимать, к чему мы, к какому ресурсу мы с тобой обращаемся.

13:49

Speaker A

Например, мы в курле там видим, не знаю, а, get v1, там, user notification, а, то есть мы проектируем endпоintты таким образом, чтобы они там содержали существительное, да, там в множественном единственном числе, неважно, как договоримся при при проектировании апи.

14:06

Speaker A

Аа и исходя из этого, да, мы понимаем, что мы хотим там получить данные уведомления и по пользователю. Хорошо, давай проваримся ещё ниже и поговорим про TTP методы и представим ситуацию.

14:21

Speaker A

Вот у нас в компании появляется архитектор, и он такой говорит: "Я сходил на встречу с заказчиком, он мне с первого взгляда не понравился. Они хотели какую-нибудь форму для создания заявок создать создать создание заявок, да, э, за тераториум". Вот. Ну и,

14:36

Speaker A

соответственно, я решил, всё, мы будем создавать тон. Угу. Вот. Сможем ли мы вообще в целом создавать? Есть ли у нас какие-то ограничения?

14:46

Speaker A

А, да, да, мы с тобой имеем ограничения в том плане, что Getмеthд он у нас с тобой не подразумевает тело запроса. Так как мы хотим создать заявку, нам нужно передать полезные данные. В заявке, например, там будет, не знаю, фамилия,

14:59

Speaker A

имя, отчество, дата, время услуги, описание услуги, какие-то детали. Все эти данные нам надо с клиента передать на сервер как в теле запроса. Gетмеthд не подразумевает тело запроса, поэтому будем использовать скорее там постмед.

15:12

Speaker A

Но если мы всё-таки решим, где мы будем передавать тогда эти параметры, если в тело запроса мы не можем положить.

15:18

Speaker A

В кри можем передавать, например. А, но здесь тоже у нас с тобой будет ограничение. Наша урла, она не резиновая, у неё там, по-моему, 2.48 символов. Вот поэтому если мы можем положить что-то в кри, то можем положить туда. Ну, если намер за там, чтобы они

15:38

Speaker A

были зашифрованные, чтобы не светить их в урле, да? То есть минус урлы передачи данных в том, что данные все видны, их можно посмотреть.

15:48

Speaker A

Вот если нам не нужно, чтобы их не надо, чтобы было видно, то мы их всё равно положим в тело запроса там соответствующего метода.

15:55

Speaker A

А ты унул вот это ограничение, оно что, типа, браузер ограничивает нас, транспорт ограничивает, рест нас ограничивает, а http протокол ограничивает. Угу.

16:05

Speaker A

Хорошо. О, ну таки, ну хорошо, мы подумали, у нас так заявка всё-таки большая, там больше тут 2.48 символов.

16:13

Speaker A

Всё, мы, соответственно, использовать ре не можем. Ну и архитектор говорит такой: "Да бахайте, дет и бахайте туда тело запроса".

16:22

Speaker A

Мы сможем только сделать вообще технически, да, но снова же вот на примере ты с нами?

16:35

Speaker A

Да, я с вами. Я пошёл за зарядкой. Говори, я слышу телефо. Супер. Так, значит, а технически, да, можем положить в гет тело запроса. Даже в постмане у нас постман не ограничивает.

16:49

Speaker A

Это, ну, есть функция, да. В посмени можно тоже там гет засунуть, но а ну, например, общалась с разработчиками, у меня почти все бэкэнды джевисты были, и они говорят, что, например, на спрингбте этот момент сразу откидывается и запрос даже не долетает до сервера. Вот поэтому

17:06

Speaker A

технически можно, но практически это очень плохая история. Угу. Да. Так получается. Ну давай попробуем подумать, где ещё мы можем передавать параметры. Ну вот мы, соответственно, у нас есть заголовки ещё, у нас есть ещё паспараметры, где мы можем, ну, конечно,

17:25

Speaker A

в паспараметрах мы данные вряд ли передадим. Просто по паспараметрам мы можем какие-то, например, запрашивать, да, данные. Ну либо, да, если, например, в постзапросе в паспараметрах тоже можем что-то положить.

17:36

Speaker A

Хорошо. Хорошо. Так, тогда получается, ну, здесь мы, э, get не можем использовать. Мы пойдём в пост использовать вместо, э, так. А если Ну нет, хотя это мы, в принципе, обсудили. Давай перейдёмся к следующим методам. У нас же есть ещё пт и патч,

17:54

Speaker A

да? Почему их разделяют? В чём их принципиальная разница? Угу. А постмеthд нам нужен для того, чтобы создать данные на ресурсе. Put мед нам нужен для того, чтобы наш ресурс там полностью изменить. То есть create и update функции.

18:10

Speaker A

Разница между этим. А, о'кей. А у патча, ну, то есть есть же пут и патч, да? Патч он отличается от пута тем, что он может частично менять ресурс. Могу привести примеры.

18:23

Speaker A

Ну давай. Например, у нас есть личный кабинет. Ну, как у пользователя там где угодно, да, например, на маркетплейсе у нас там есть личные данные, например, там, что фамилия, имя, отчество, там номер телефона, почта. Мы с тобой, если реализуем изменения этих данных через

18:41

Speaker A

пут, то наш клиент должен передавать всегда все данные. А независимо там мы меняем только фамилию, только email, только email, фамилия, имя. В общем, мы всегда пять параметров должны с тобой передавать на наш сервер. В патче, например, мы хотим изменить только

18:59

Speaker A

email, а мы, собственно, будем передавать только email, одно поле. Вот. И, соответственно, разница в том, что сервер в патче не ожидает полностью все данные и перезапишет ровно только то поле, которое пришло.

19:11

Speaker A

Хорошо, хорошо. Давай перейдём к Иделиту, поговорим про него. И, ну, про делит всё понятно, да? Берёт и удаляет. А вот есть же логическое удаление, да, и физическое. Их ещё говорят софт и хард delete вот в чём здесь отличие.

19:26

Speaker A

В чём здесь отличие? А, всё тот же личный наш кабинет, допустим, а, и нам бизнес-заказчик говорит, что мы хотим хранить с тобой, данные всех пользователей, которые к нам когда-либо приходили. Даже если они удалили свой профиль, мы хотим иметь по ним

19:41

Speaker A

информацию. Что делаем? В базе данных, в ресурсе, где у нас хранятся пользователи, например, табличка users, мы с тобой делаем булевое поле, там deleted, is deleted, как угодно его называем. А, и если, значит, клиент, пользователь удаляет свой профиль, мы

19:57

Speaker A

просто там помечаем как delete true. А на клиент, например, не отдаём такие там профили. Ну, для статистики, для отчётности, может быть, храним, чтобы там использовать, либо какие-то ещё у бизнес-заказчика есть идеи, э, там, потребности, чтобы считать, например, да, сколько там всего было профилей

20:16

Speaker A

пользователей за весь момент, удалённых, неудалённых. А как мы поступим с множественным удалением? Ну, то есть вот нам нужно удалить много объектов, да, много эдишников каких-то передать. Угу.

20:26

Speaker A

Куда мы можем их положить? А мы как это делали? Мы смотрели, значит, допустим, вот у нас что у нас там было?

20:39

Speaker A

У нас были контракты, сущности контракты и, э, и договоры внутри контрактов. Договоров было всего 10, максимум 10 в рамках одного контракта. И мы приняли решение, что мы, например, будем это передавать просто в quy параметрах массивом, потому что 10 уместится,

21:01

Speaker A

айдишники небольшие. Как ещё можно передавать? Можно передавать в теле запроса, хотя delete он, ну, снова же не подразумевает, что у него будет использоваться тело запроса. Но, например, если айдишники огромные, то можно туда засунуть. Либо есть третья функция, как, а, агрегировать данные. А,

21:22

Speaker A

например мм у тебя маркетплейс и у тебя корзина. Ты в корзину добавил 100 товаров. Ты хочешь, например, удалить всю корзину, то ты не будешь передавать все 100 товаров. Ты передашь айдишник этой корзины снова же. Например, там в qu

21:41

Speaker A

параметрах. И вся твоя корзина удалится. Угу. Да. Хорошо. Давай попробуем разобрать такой кейс. Представим, что я не знаю, я написал опирку, которая несёт себе справочных городов.

21:55

Speaker A

Вот. Ну и она была публичная, торчала в наружу. И я увидел, что у меня там клиентов, не знаю, штука, две штуки просто людей, которые юзают. Я просто посмотрел там метрики с разных айпишек её дёргают. Я подумал, что можно

22:09

Speaker A

монетировать и всё. Я подумал так, её, значит, нужно обезопасить, да, как закрыть пользни и открывать для тех, кто закинет мне навер по номеру телефона 1.000 руб. Вот, соответственно, каким способом я могу её так обезопасить, закрыть её от клиентов

22:26

Speaker A

и выдавать её? Это шикарный вопрос. Я его ждала на всех собеседованиях. В общем, я расскажу, как у нас это делается, потому что мы прямо вот только что занимаемся монетизацией своей опишки.

22:39

Speaker A

А мы внедряем апиключи. Апиключ, что это такое? Это такой специальный набор символов, который передаётся нашим потребителям для того, чтобы, во-первых, для идентификации авторизации, во-вторых, чтобы на ключно вешивать рейд-лимиты. Что такое рейдлимиты? Это ограничения по использованию API. Рейт-лимиты можно

23:02

Speaker A

навесить там по запросам в день, в секунду, в минуту, можно по квотированию навесить. И, собственно, ты говоришь то, что, ну, вот, например, я тебе выдаю апи ключ, а пользователь вешаю на него там 10 бесплатных запросов. С одиннадцатого запроса всё, у тебя уже там будет,

23:20

Speaker A

например, возвращаться какая-то ошибка. Это будет значить, что твой там демопериод кончился и закидывай мне деньги на карточку. А и всё, собственно, по квотам ты реализуешь проверку, что там 10 запросов на ключ исчерпано. Всё, теперь только там дальше идёт проверка,

23:39

Speaker A

что если пользователь на этот ключ оплатил деньги, то а дальше мы ему предоставляем доступ. Ну а иначе не предоставляем.

23:48

Speaker A

Угу. Хорошо. Слушай, так один вариант мы назвали. Давай попробуем подумать ещё какие-нибудь варианты подороже. Может быть, ещё дешевле можно вариант какой-то найти.

23:58

Speaker A

А ещё способ монетизации, а по подписке, например, снова же, да, ты реализуешь публичную опишку и там говоришь то, что, ну, предоставляешь разные функции подписок.

24:13

Speaker A

А в подписку снова же закладываешь там, а, ну, допустим, по РПСУ, по Request per second количество запросов, ну, не знаю, в секунду заводишь. Вот. И здесь снова же мм ограничиваешь стоимостью м ну по количеству таких-то вот запросов за определённый период.

24:33

Speaker A

Угу. Хорошо. Так, это получается по ключу мы закрылись по IP. А если мы хотим прямо систему какую-нибудь авторизации, регистрации пользователей вводить, как мы будем её использовать?

24:45

Speaker A

Ну, как она вообще в целом устроена? Мы, допустим, с тобой вводим новый сервис авторизации аутентификации там плюс идентификации. В ней будем хранить всех наших пользователей, которые к нам приходят. А будем хранить их там данные, м будем хранить, э,

25:04

Speaker A

роли, да, например, если мы авторизацию ещё делаем, а как это будет работать? Пользователь к нам приходит с ключом, с токеном.

25:13

Speaker A

А токенов тоже у нас может быть пару видов. Мм, кстати, вот апи ключи. Только для безопасности АИ ключей я бы не делала, потому что тоже на примере двух компаний Без она ограничивала этот доступ. То есть, например, используйте апи ключ, но хотя бы ещё с токеном. Ну

25:30

Speaker A

там Birрер токен, GVT токен. Вот, собственно, мм, приходит пользователь, мы проверяем его по там параметрам, которые он предоставляет. Ну, креды, да, либо если это человек, то там логин пароль, не знаю, что угодно мы реализуем. Если это система, то у неё

25:45

Speaker A

тоже какие-то должны быть параметры, идентификаторы. А там client ID, client Secret. Ну и, собственно, проводим здесь авторизацию, клиента системы и предоставляем либо не предоставляем доступ.

25:59

Speaker A

Угу. Хорошо. Хорошо. В целом достаточно вариантов. Так. А, а, нет, испугался, думал, у меня светло включили. А давай поговорим про безопасные и индопотентные методы. Что это за методы такие? А это методы, которые не изменяют данные на данные ресурсы на сервере. К ним относится

26:27

Speaker A

get, к ним относится head. А мне кажется, ещё к ним относится options, наверное, всё, но возможно ещё и треace, но здесь я подробно не расскажу. Вот. Но по гетхеду мы что запрашиваем? Запрашиваем данные с сервера, мы читаем, поэтому данные у нас

26:49

Speaker A

не изменяются, поэтому считаются они безопасными. Угу. А что относится к адапотентным? Относится снова же get, относится head, относится put, delete.

27:04

Speaker A

А, ну из основных всё так получается у нас пост он не депотентный не является.

27:10

Speaker A

А можем ли мы его как-то сделать идптом? Да, конечно, мы с тобой можем передавать с клиента ключ патентности.

27:18

Speaker A

Ну, то есть за генерацию здесь будет отвечать клиент, да, этому ключа, да? Хорошо. Хорошо. Слышала что-нибудь про Open API?

27:26

Speaker A

Спецификация Open API. А, да, даже у нас был подход Open App first, когда мы проектируем в Свагере опишку, а, в ямол и потом её передаём уже разработчикам для последующей реализации. То есть, ну, у тебя был опыт, да, в написании

27:43

Speaker A

openпишек? Да, в Свагере пишу. А в чём отличие Openпе от Свагера? Openap - это м сам вид спецификации.

27:52

Speaker A

Свагер - это инструмент, где мы можем описать эту спецификацию, где она, например, у нас может храниться. То есть, ну, хранится как, а храниться она, скорее всего, будет на бэкэнде, но мы с тобой Свагер - это просто как юайная часть, да, которая

28:08

Speaker A

представляет, как это будет выглядеть. Через мы с тобой можем почитать документацию, написать, ну, в подходе Open First можем потестировать опишку, потому что снова же у нас представлены методы, которые в ней реализованы.

28:24

Speaker A

Можем подёргать сервер наш. Чем она может быть полезна разработке? Кроме того, что они видят контракты не в конфлюенции описаны, да, а именно, ну, там, не знаю, ну, давай так, в гие, да, он лежит, его прихранили, загрузили. Вот чем он может быть полезен для разработки

28:45

Speaker A

ещё? А он, во-первых, показывает структуру. То есть аналитик в конфлюнтесе может там её как угодно, да, писать, но когда ты описываешь в контракте openпи, у тебя чёткое определение, там какие схемы есть, какие свойства есть, там обязательные, необязательные поля. Понятно, что это и

29:03

Speaker A

в конфлюнсии можно описать, но здесь всё-таки она есть своя структура, как она описывается, и её нельзя прочитать, ну, неоднозначно, нежели если мы будем сравнивать с Конфлюенсом. А возможно ли вообще использовать для код подхода?

29:20

Speaker A

Для чего? Ну, для кода генерации, к примеру. Код генерации. Ну, имеешь в виду написать в Openпе, передать разработчикам, чтобы они из этого код сделали? Ну, в коде забить.

29:32

Speaker A

Ну да, хотя бы какой-то скелет к себе положили, получили из Опнахи. Конечно, конечно. Ну, собственно, да, у нас в этом подход и заключался Openфs, что мы писали опишку, передавали её в яму разработчику. Для него это было, если там не м не скелет, то даже уже

29:52

Speaker A

чуть побольше, потому что, ну, мы как аналитики прямо полностью описывали там и дескрипшены, и реквайды, и схемы. Ну, разработчики какие-то данные меняли, но всё равно они прямо очень хорошо переиспользовали. Давай попробуем разобрать с один из окон пишки. Вот, э,

30:12

Speaker A

представим, что у нас объект, он может иметь разную вложенную структуру. Ну, представим, что у нас объект грядка, да, и мы в эту грядку можем посадить как овощи, так и фрукты. Ну и, соответственно, у овощей будет своя атрибутика, у фруктов своя. Вот. Можем

30:27

Speaker A

ли мы, как мы будем, не знаю, поддерживать разную вложенность на уровне объекта? Всё. То есть у нас одна грядка и, а, под грядкой у нас будет вложенность с объектом фрукты. Вторая второй объект будет с овощами. И внутри этих объектов

30:44

Speaker A

у нас будет перечисление параметров относящихся к А можем ли мы как-то избежать перечисления отдельных объектов в, ну, то есть не заводить. У нас получается, если видите по структуре, да, джисона, например, у нас будет поле объект, ой, полегрядка. Это будет

31:01

Speaker A

поле объектом. В нём вложенность ээ что там будет овощи, фрукты, и они свои, ну, то есть они будут необязательные, да, потому что на грядку мы можем посадить либо то, либо другое на одну. И получается овощи и фрукты - это тоже

31:14

Speaker A

свои объекты. А можем ли мы как-то делать взаимоисключающие? Ну, то есть использовать такой принцип, да, из ОП, как полиморфизм?

31:23

Speaker A

Так. Ну, смотри, здесь важно понимать вообще будет ли вложенность под фруктами и овощами, либо если просто у грядки идёт перечисление, из чего она состоит, то, не знаю, в массив можем положить.

31:38

Speaker A

Угу. Ну давай, чтобы контекст не было. Слышал что-нибудь про такие такие конструкции, как one of, any of, all of?

31:46

Speaker A

Да, поняла. Yeah.

Topics: системный анализ собеседование интеграции REST Kafka UML BPMN C4 микросервисы iGaming

Учить по этому видео

- [Карточки по этому видео](https://sozai.app/ru/tools/flashcard-maker/?from=transcript&id=87584)
- [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=87584)
- [Кроссворд по этому видео](https://sozai.app/ru/tools/crossword-maker/?from=transcript&id=87584)
- [Филворд по этому видео](https://sozai.app/ru/tools/word-search-maker/?from=transcript&id=87584)
- [Шпаргалка по этому видео](https://sozai.app/ru/tools/study-guide-maker/?from=transcript&id=87584)

Бесплатно, составлено ИИ по этой расшифровке. Без регистрации.


---
This is the markdown twin of https://sozai.app/transcript/400k-real-system-analyst-interview-igaming/ — the same content, without the markup.
Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back.
Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/