Speaker A
Давай потихоньку будем переходить к основе технической части собеседования, наверное, а потом, если останется время, ещё немножко поговорим про общий организационный вопрос.
Реальное собеседование на системного аналитика с зарплатой 480к: трассировка требований, анализ формулировок, метрики качества работы аналитика, оркестрация саг и проектирование системы на примере кин
Key Takeaways
- Качественное требование должно быть однозначным: явно указывать интерфейсы, роли пользователей и системы.
- Трассировка требований позволяет проследить связь от бизнес-целей до конкретных функций, даже если используется Confluence/Jira вместо специализированных инструментов.
- Метрики работы аналитика включают точность оценок, время анализа задачи и количество уточнений от разработчиков.
- Проектирование распределённых систем требует продуманной обработки ошибок и компенсирующих действий в сагах.
What the video covers
- Кандидат разбирает технические вопросы собеседования на системного аналитика и архитектора.
- Обсуждается трассировка требований: от бизнес-требований к пользовательским и функциональным, с помощью матрицы трассировки, Confluence и Jira.
- Разбирается пример требования о русском языке интерфейсов: неоднозначность понятий 'справочная информация', ролей пользователей и систем.
- Обсуждаются метрики качества работы отдела системного аналитика: точность оценок задач, время анализа, понятность требований разработчикам.
- Рассматривается оркестрация саг и обработка ошибок в распределённых сервисах, включая каскадный откат.
- Проектируется сервис авторизации и регистрации с выделением провайдеров, а также сервис нотификаций с шаблонами.
- Моделируется система продажи билетов для оффлайн-кинотеатра: сущности сеанса, мест, рядов, вопрос о необходимости брони.
- Видео носит образовательный характер и показывает ожидания от кандидата уровня аналитика-архитектора.
Chapters
- 00:00Введение и переход к технической части
- 03:00Трассировка требований и матрица трассировки
- 03:23Разбор неоднозначного требования о русском языке
- 07:20Метрики качества работы отдела аналитики
- 15:15Оркестрация саг и обработка ошибок
- 25:20Проектирование авторизации и сервиса нотификаций
- 45:25Кейс: система продажи билетов в кинотеатре
- 65:00Модель данных и завершение
Full Transcript — Download SRT & Markdown
Speaker A
Да, конечно. А начнём с базы, что важно любому аналитику, ну, и архитектору, в том числе это требования.
Speaker A
Да, конечно. А начнём с базы, что важно любому аналитику, ну и архитектору, в том числе это требования.
Speaker A
Мм, сейчас, сейчас сформулирую. А прослеживание источников, мм, ну как, ну да, давай так, источников требований от самого, ээ, начала, да, вот условно от бизнес-требования, которое породило пользовательское требования, которое поразило функциональное требования. И вот оно там выливается в требовании, не
Speaker A
По требованиям расскажи, что такое трассировка требований и как её можно реализовать. Трассировка требований — это, скажем, механизм, методика, что ли, а прослеживание.
Speaker A
матрица трассировки. А, то есть где ты, ну, по-моему, я, честно говоря, ни разу это вживую не делал, а-а в табличном виде, ну, по сути, прописываешь маппинг, да, бизнес-требований на, ну, и дальше вот ниже по уровням.
Speaker A
Мм, сейчас, сейчас сформулирую. А прослеживание источников, ну как, да, давай так: источников требований от самого начала, да, вот условно от бизнес-требования, которое породило пользовательское требование, которое породило функциональное требование. И вот оно там выливается в требование, не знаю, к тому, что у тебя должна быть такая табличка. То есть от самого, скажем, глубокого требования ты можешь проследить связь до самого высокого уровня требования. И насколько я знаю, чуть ли не единственный, наверное, способ это реализовать — матрица трассировки. Где ты, по-моему, честно говоря, ни разу это вживую не делал, а в табличном виде, по сути, прописываешь маппинг бизнес-требований на дальше вот ниже по уровням.
Speaker A
или или в джи там у тебя таска потом связывается с несколькими страницами вики, то это тоже, можно сказать, требований. Ну, в целом, в целом, да, пожалуй, что, ну, если мы говорим ещё про конфлюнс, тогда, а, ну, в целом, да,
Speaker A
Ну, на самом деле, скорее всего, ты встречался с другими способами трассировки требований, просто, может быть, не рассматривал это как именно инструмент трассировки. Допустим, те же самые требования, если описываешь где-нибудь в Confluence и потом связываешь ссылки из одного места в другое, или в Jira у тебя таска потом связывается с несколькими страницами вики, то это тоже, можно сказать, трассировка требований. В целом, да, пожалуй, если мы говорим ещё про Confluence, это можно реализовать через идентификаторы требований, как раз через кросс-ссылочность, то есть с конкретным идентификатором требования связывать.
Speaker A
Угу. С Архимейдом случайно не доводилось тебе работать? Нет, с Архимейдом не работал. О'кей. Ладно. Там был хороший пример прямо по трассировке.
Speaker A
Угу. С Archimate случайно не доводилось тебе работать?
Speaker A
Все интерфейсы пользователя поддерживающие, да, взаимодействие пользователя с системой, включая справочную информацию, должны быть выполнены на русском языке.
Speaker A
Нет, с Archimate не работал. Окей. Ладно. Там был хороший пример прямо по трассировке.
Speaker A
дополнительные интерфейсы или если мы говорим вообще про, ну, как бы графический интерфейс, да, то может быть это там какие-то, я не знаю, всплывашки, попапы, да, ну, информационные элементы, короче.
Speaker A
А, м, окей. Смотри. У тебя есть пример такого требования: «Все интерфейсы взаимодействия с пользователем системы, включая справочную информацию, должны быть выполнены на русском языке». Скажи, всё ли в порядке с этим требованием?
Speaker A
Ну, тут можно, я не знаю, чисто формально докопаться то, что на русском языке можно и транслитом написать, да? То есть тут, наверное, можно ещё и про, э, как раскладку, да, явно прописать.
Speaker A
Все интерфейсы пользователя, поддерживающие взаимодействие пользователя с системой, включая справочную информацию, должны быть выполнены на русском языке.
Speaker A
И возможно там для каких-то ролей, а если для каких-то, ну то явно прописать для каких именно ролей, да, у нас должно быть на русском, а можно для других, ну, вдруг там на английском должно быть, да?
Speaker A
Всё ли с этим требованием, как ты его понимаешь?
Speaker A
Угу. У, может быть, предполагается, ну, там, условно, есть несколько, ну, типа 1С там, э, зарплаты и персонал и 1С там, я не знаю, управление предприятием. И вот там разные интерфейсы для разных пользователей, соответственно, разные системы. И то есть тут тоже может быть разночление.
Speaker A
Ээ, ну нет, не всё. Непонятно, все интерфейсы какие именно, да? То есть было бы хорошо их явно определить, включая справочную информацию. Что такое справочная информация? Это какие-то дополнительные интерфейсы, или если мы говорим вообще про графический интерфейс, то, может быть, это какие-то, я не знаю, всплывашки, попапы, информационные элементы, короче.
Speaker A
Хороший вопрос. Э, давай так. Я не знаю, но я попробую порассуждать. М, какие метрики качества работы отдела?
Speaker A
Вот, должны быть выполнены на русском языке. Но здесь, может быть, «выполнено на русском языке» — неоднозначно. Можно, я не знаю, чисто формально докопаться до того, что на русском языке можно написать и транслитом, да? То есть тут, наверное, можно ещё и про раскладку явно прописать.
Speaker A
разработки оценивают задачи там вместе с тестировщиком, так и аналитики тоже, ну, примерно хотя бы пальцем небо оценивают то, что, ну, о'кей, на проработку этой задачи у меня уйдёт, допустим, спринт. А насколько, собственно, оценки вообще по, ну, насколько оценки бьются с реальностью,
Speaker A
Мм, что ещё? Угу. Ну вот, наверное, пользователи. Тут можно ещё добавить про роль пользователя, да? Очевидно, ну, не очевидно, скорее всего, у нас есть разные категории пользователей, разные роли. И возможно, для каких-то ролей должно быть на русском, а для других, вдруг, на английском, да? Так что для каких именно ролей явно прописать.
Speaker A
с темно аналитике, но это, конечно, скорее не совсем та метрика. А дальше, дальше, дальше. Значит, нам возможно есть смысл, ну, блин, прово, знаешь, это как опрос НПС, только среди не не пользователей, а среди разработчиков из разряда. Как ну как как вы оцениваете
Speaker A
И с системой: если у нас одна система, то такое написание допустимо. Если же несколько, то лучше прописать, какого пользователя с какой системой. Угу. Может быть, предполагается, например, несколько систем: 1С зарплата и персонал и 1С управление предприятием, и там разные интерфейсы для разных пользователей, соответственно, разные системы. Тут тоже может быть разночтение.
Speaker A
аналитика. Аа, то есть насколько она ему понятна и насколько много приходится разработчику тратить времени, чтобы довыяснить, да, доуточнить какие-то детали у аналитика.
Speaker A
Угу. А, окей. А вот скажи, как архитектор, как потенциальный лид аналитиков, какие оценки, точнее метрики качества работы отдела системного аналитика ты мог бы выделить?
Speaker A
точки зрения того, что тесткейс вообще проверяет то, что было задумано, да, и, соответственно, на финальном этапе, когда тестировщики уже, а, там проверяют ту или иную фичу, то, мм, ну, условно проверять на соответствие того, что было сделано, тому, что было описано, да? А
Speaker A
Хороший вопрос. Давай так. Я не знаю точно, но попробую порассуждать. Какие метрики качества работы отдела? Может быть, конкретного системного аналитика даже. В целом, абстрактного системного аналитика. Слушай, из очевидного, наверное, это... сейчас, если предположить, что мы оцениваем задачи, как разработчики на груминге перед спринтом вместе с тестировщиком, так и аналитики примерно пальцем в небо оценивают: на проработку этой задачи у меня уйдёт, допустим, спринт. А насколько оценки вообще бьются с реальностью? Раз. А сколько задача проводит на этапе анализа? То есть между тем, как ты её взял, и тем, как ты её отдал? Почему-то очень хочется сказать что-то про WIP-лимиты, из разряда, сколько у тебя задач может быть в статусе у системного аналитика, но это, конечно, скорее не совсем та метрика.
Speaker A
Может ну разработчик а, сложен в восприятии, да, и он, ну, ну вот не получается у него делать то, что написано. То есть тут такой момент, а, ну, то есть ты имеешь в виду непосредственное расхождение с описанием исал как таковым, которое есть в Таске.
Speaker A
Дальше... значит, возможно, есть смысл, знаешь, провести что-то вроде NPS, только среди не пользователей, а среди разработчиков: как вы оцениваете задачи вот конкретного этого аналитика? Эта мера нацелена на то, чтобы определить качество проработки задачи и количество вопросов, которые возникли у разработчика после того, как он взял задачу конкретного аналитика. То есть насколько она ему понятна и сколько приходится разработчику тратить времени, чтобы доуточнить детали у аналитика.
Speaker A
экспертизы в том, как ну технически более правильно, да, реализовать ту или иную фичу. Вот.
Speaker A
Угу. Дальше можно... Это, конечно, косвенная метрика. Аналитики могут взаимодействовать с тестировщиками на этапе, в параллель с разработкой: тестировщики пишут тест-кейсы, а аналитик их проверяет. С точки зрения того, что тест-кейс вообще проверяет то, что было задумано, и, соответственно, на финальном этапе, когда тестировщики проверяют ту или иную фичу, — условно, проверять на соответствие тому, что было сделано тому, что было описано. Тут, конечно, метрика скользковатая, потому что задействует не только аналитика, но и разработчика. Может, разработчик сложен в восприятии, и у него не получается делать то, что написано.
Speaker A
придумать. Если функционал, допустим, давно не разрабатывался, да, ну, в смысле, он был разработан и больше не дорабатывался, то тогда, ну, к дате изменения привязываться, ну, бессмысленно. Тут скорее может быть в формате какого-то периодически повторяющегося ревью, там, допустим, а ревью кода и ревью
Speaker A
То есть ты имеешь в виду непосредственное расхождение с описанием, ИСАЛ как таковым, которое есть в таске?
Speaker A
Некоторые, да, некоторые вещи действительно полезные. Актуальность документации тоже важная. Но да, и в целом как минимум её можно было бы поддерживать с точки зрения того, насколько процентов там, если система делится условно на те же самые бизнес-функции, бизнес-сус там и так
Speaker A
Ну, грубо говоря, да. Но это палка о двух концах: системный аналитик может быть недостаточно погружён в контекст, и разработчику будет, скажем, виднее, потому что у него больше экспертизы в том, как технически правильнее реализовать ту или иную фичу. Вот.
Speaker A
Давай потихоньку к архитектуре перейдём. А я так понимаю, ты тоже с микросервисной архитектурой не понаслышке знаком уже.
Speaker A
Угу. Окей, это, наверное, то, что касается постановки задач. И здесь можно было бы ещё отдельно выделить подгруппу: актуальность документации. То есть системные аналитики занимаются поддержкой документации в актуальном состоянии, соответственно. Здесь какую метрику придумать, конечно, непросто. Если функционал, допустим, давно не дорабатывался, то привязываться к дате изменения бессмысленно. Тут скорее может быть в формате периодически повторяющегося ревью: ревью кода и ревью документации на соответствие. Конечно, слегка пахнет фантастикой, потому что это достаточно трудоёмкое мероприятие. Ну окей, хорошо. В принципе, этого достаточно. Вот я понял посыл.
Speaker A
Угу. А-а, да, в принципе, ну, transactional outbox, event sourcing, а они у нас в сочетании шли, аэ, SAGA, Seqrs, BFF, external gitway, э, но части AP composer можно, в принципе, назвать же database perвиice. Аэ, ну, ну, давай пока вот на этом
Speaker A
Некоторые, да
Speaker A
Да, смотри, значит, в базе данных каждого сервиса добавляется, ну, скажем, служебная таблица, там аудит, ну, неважно, как ты её назовёшь, а, да, в которую при каждой операции, э, ну, при каждом, по сути, инсерте или апдейте или долите, ну, короче, при каждой операции
Speaker A
изменения, а помимо, собственно, целевой какой-то таблицы ещё, а, пишется запись, э, в эту табличку аудита о том, что была совершена такая операция. с такой, ну, вот с таким объектом, да, там вот с таким идентификатором, в такой таблице, условно, такое старое значение, такое
Speaker A
новое. То есть, ну, таблица изменений, по сути, как этот change data capture capture, а для чего она нужна? А мы таким образом можем фиксировать, собственно, все изменения, да, которые происходили с тем или иным объектом. И, но само по себе в
Speaker A
этом как будто смысла большого нет, но в сочетании с ивентсорсингом, который у нас назывался и называется ивентстримингом, короче, что происходит?
Speaker A
Аа в каждом продукте раскатан платформенный компонент, который э вычитывает ну по-моему раз в минуту, что ли, эту таблицу, а-а, и отправляет э всю вычитанную информацию в кавкатопик, ну, в специальный отдельный кавкатопик, и дальше очищает эту таблицу, то есть
Speaker A
селектит и дальше всё долитает. Вот. Ну, соответственно, чтобы таблица не распухала. Дальше всё это пока к топику пролетает до датаслоя, до ДВХ, где, по-моему, Спарк, да, по-моему, ачпак разгребает, значит, эти кавкатопики и уже дальше по внутренней кухне дата датаслоя
Speaker A
раскидывает там данные, улетают в Greгenplan. Как раз там вот change data capture реализовывается, ну, для вообще работы с историческими данными. часть улетает в Кассандру, потому что в Кассандре, значит, витрины данных строятся, ну, для того, чтобы была возможность поверх этих
Speaker A
витрин реализовать дата апи, ну, чтобы там продукты могли с какими-то историческими данными работать. А и в Кликхаус, по-моему, для аналитики, насколько я помню. Вот. А-а, то есть таким образом мы можем позволить себе на уровне продуктов, да, продуктовых баз не
Speaker A
хранить какие-то сильные исторические данные, аа, ну, соответственно, чтобы несчастная пазгря не раздувалась до каких-то безобразных размеров. Вот. Угу. Сливать там, условно всё, что, я не знаю, старше, ну, короче, какого-то юридически определённого лимита, да, там старше года, двух, трёх,
Speaker A
всё в датаслой и всё. А, понял. Плюс, э, у этого оказался ещё второй, э- не самый очевидный, но классный бонус. То, что другие продукты, ну, там, условно, любой другой продукт смежный, может точно также подключиться к этому кавкатопику и затягивать к себе
Speaker A
какие-то данные, которые ему необходимы. То есть те данные, которые тебе нужны, допустим, в асинхронном формате, там справочники какие-нибудь, да, например, или там ещё что-то, а ты можешь спокойно не идти напрямую, да, синхронно в продукт, не генерировая нагрузку, не
Speaker A
идти в датаслой, потому что датас-слой бог знает, когда будет сделано, да? Ну, целёвка, как обычно, целёвка долго делается. Вот. А ты можешь просто подключиться к авкатопику, то есть это разрешалось, и вычитать оттуда. Ну, условно, там, естественно, у тебя там
Speaker A
полный атрибутивный состав какого-либо объекта агрегата, да, и ты можешь оттуда брать только то, что тебе нужно, да, и прикапывать у себя где-то локально в базе данных. Там условно гишник и нужно тебе атрибут. Вот. То есть это прикольный такой инструмент получился.
Speaker A
Good. Good. Я понял. Хорошо. Здесь вижу, что знаешь, о чём говоришь, как пониму. А по сагам скажи, доводилось ли тебе проектировать оркестрацию? Может быть, какие нюансы того, как её использовать можешь назвать?
Speaker A
А, слушай, с оркестрацией вживую практически не работал. В самокате одно время пытались завести комунду. Потом, по-моему, на какой-то версии решили от комунды уйти, пытались внедрить temporal. Tempтеal тоже не взлетел, насколько я помню. Почему именно, честно говоря, не подскажу. Возможно, дело было
Speaker A
банально в накладных расходах и в организационных моментах, что, ну, а никто сильно не хотел с ним возиться, разбираться. Э, вот поэтому я успел только немножко тогда документации почитать, и в итоге мы просто ушли обратно на хореографию. Вот.
Speaker A
Угу. Вкратце расскажешь, чем хореографии отличается от оркестрации. А, да. Ну, то есть в случае хореографии у тебя в рамках каких-то сквозных сценариев сервисы сами знают, э, к какому сервису им дальше нужно обратиться, да? То есть они самостоятельно как бы дальше перенаправляют запросы,
Speaker A
скажем так. А в случае оркестратора есть один какой-то элемент, да, связующий, э, к которому приходят все запросы от всех сервисов в рамках любого сценария. И дальше уже оркестратор перенаправляет ну тот или иной запрос уже какому-либо другому сервису. Вот, соответственно, в
Speaker A
случае саги а получается, что а-а если мы делаем сагу через оркестратор, то а ты все компенсирующие, ну, откатывающие по сути транзакции должен закладывать в оркестратор, да, так как он отвечает за всю эту маршрутизацию. А в случае хореографной хореографной саги
Speaker A
через хореографию ты уже должен на стороне каждого из сервисов закладывать вот эту логику откатов.
Speaker A
Как заложить? Ну какими способами можно на стороне сервиса заложить вот эту вот обработку компенсирующей транзакций?
Speaker A
Ну условно как бы твой сервис же знает, да, куда он дальше отправляет запрос. Если он получает отлуп, да, как, ну, какую-то ошибку то соответственно там может специально договориться и получать какую-то конкретную кастомную, да, ошибку там с кастомного кодом, типа
Speaker A
сага failed. Ну, не знаю, а то, соответственно, это является триггером для того, чтобы уже запускать откат за своей стране. Как сервис должен понять, что вот у тебя, допустим, в рамках саги идёт вызов нескольких сервисов. Ну, пусть это будет оркестрация та же самая.
Speaker A
Можно и на хореографию это приложить в каком-то смысле. Э, вот у тебя сервис выполняет какой-то определённый шаг.
Speaker A
Допустим, это какой-нибудь второй шаг в саге, их всего четыре шага. На втором шаге сервис на своей стороне, ну, взаимодействует там в саге несколько сервисов, соответственно, с разными своими доменами, своими базами и так далее. И вот на втором шаге у тебя всё
Speaker A
о'кей, а на третьем шаге у тебя сага валится. Как понять сервис, который на втором саге, на втором шаге саги находится, что нужно коммитить базу или не нужно комитить базу и как провести потом откат, если что, если будут компенсировать транзакции.
Speaker A
Да. Ну, смотри, здесь получается, что, а, если у нас мы говорим про цепочку синхронных взаимодействий, да, то мы можем предположить, что у нас идёт каскад, типа там первый запрос, потом внутри него второй, третий, четвёртый.
Speaker A
Соответственно, если мы получаем на каком-то из шагов ошибку, то у нас также ошибка каскадам и полетит обратно. Если мы говорим про там асинхронщинов, ну хоть на каком-то из этапов или не на каждом, то, соответственно, тот сервис, на стороне которого там происходит
Speaker A
ошибка, должен в какой-то топик специально под это оборудованный, да, отправить сообщение, что вот конкретно эта операция зафейлилась, и, соответственно, уже другой сервис должен этот топик вычитать и каким-то образом обработать.
Speaker A
Угу. Ну ладно. О'кей. О'кей. Давай перейдём к актическому примеру. По теории мы тут поговорили достаточно, я думаю. А-а, что необходимо будет сделать? Смотри, мы спроектируем небольшую архитектуру аэ процесса, который, собственно, мм ну, у нас будет небольшая система, которая даёт возможность пользователям
Speaker A
зарегистрироваться либо авторизоваться. И при регистрации, то есть для новых пользователей им на почту отправляется в приветственное письмо. Аля, добро пожаловать в систему.
Speaker A
Аэ, делаем, несмотря на то, что система небольшая, крохотная такая, сразу в микросервисах, а вот от тебя что необходимо? Ну, основные компоненты, собственно, сервис, которые реализуют этот процесс, как они друг с другом взаимодействуют. Просто можешь словами рассказать, там стрелочками показать, ну, и всё. А там
Speaker A
дальше уже по ходу поговорим, с тобой какие-то вопросы задам. Угу. Так, о'кей. Так а значит, у нас есть авторизация, а, регистрация и авторизация. Да, извини, я не записывал, я просто слышал.
Speaker A
Ага. Да, ничего, я, если что, напомню. Ага. И регистрация, авторизация. И для пользователей которые зарегистрировались, то есть новые пользователи практически, им на почту отправляется приветственное письмо. Угу.
Speaker A
Так. И у нас сразу и у нас микросервисы. Угу. О'кей. А так м, какое количество пользователей у нас в этой системе?
Speaker A
Ну, небольшое, условно, 1.000 пользователей в месяц. 1.000 пользователей в месяц. А так 1.000 новых пользователей в месяц, да?
Speaker A
Да. 1.000 новых пользователей в месяц. Угу. Так, о'кей. А, ну я не я не думаю, что это для задачи важно, но тем не менее. А размер письма, ну какой-то видимо незначительный.
Speaker A
незначительные. То есть там нет никаких атачтов, ничего такого, просто обычная фронтовая вёрстка и текстовое сообщение пря.
Speaker A
Угу. О'кей. О'кей. А так понятно. Так, ну ладно, ладно, давай попробуем. Так, а web тут у нас только веб или мобилка тоже есть? Или только? Давай, давай упростим. Только веб.
Speaker A
Только веб. О'кей. А, ну провайдер, а, имейлов у нас, ну, просто какой-то абстрактный, да?
Speaker A
Какой-то абстрактный из всех ту, да. Угу. О'кей. Блин, что большой-то такой. А, ладно, пусть будет так.
Speaker A
Так, значит, только веб у нас есть. Так, а пользователи? А, ну раз они регистрируются, есть какая-то какое-то различие в, ну, какие-то разные категории пользователей или это просто абстрактные наши пользователи?
Speaker A
Пускай все будут пользователи, да. Ну, то есть нет каких-то отдельных ролей у них, нет каких-то отдельных категорий.
Speaker A
Это обычная пользу это. О'кей. Так, ну, значит, у нас здесь получается регистрация авторизация да, с точки зрения их сценариев, которые они проходят в рамках нашей задачи.
Speaker A
Аа, так, дальше. Если у нас только веб, а смотри мы ну, скажем, какой-то более-менее быстрое MVP хотим или более-менее правильное решение?
Speaker A
Давай правильное решение. То есть мы смотрим вперёд, думаем, что у нас будет развиваться система, скорее всего, потом появятся какие-то новые каналы, уведомления ещё.
Speaker A
Пока что оно как бы такое, но мы сразу нацели на то, что будем быстро расти.
Speaker A
Угу. А может быть такое, что в будущем мобилка, допустим, появится или или точно нет?
Speaker A
Может появиться. Может появиться. Так, мобилка может появиться. Могут появиться новые каналы м сообщений. Так, ну смотри, если мобилка может появиться, то можно сразу заложить, например, нам какой-то BFF, да, типа web BFF.
Speaker A
А, и, соответственно, если у нас появится мобилка, то мы сможем отдельно, ну, мобилку, да, поднять уже отдельный BFF и окатить отдельно веб, отдельно мобилку без каких-либо зависимостей между ними.
Speaker A
Плюс мы сможем ещё разделять и функциональности. То есть на веб может быть одна функциональность, на мобилке другая. То есть это нам немножечко развяжет руки в дальнейшем.
Speaker A
Угу. Вот. А так, значит, у нас есть регистрация и авторизация. Значит, у нас, а, есть некий, а, ну, usеer севис, мм, который в себе хранит, э, ну, собственно, пользовательские данные, да, то есть, э, там, я не знаю, аа, и для авторизации, в принципе, он,
Speaker A
ну, смысл разносить авторизацию регистрация с учётом того, что у нас 1.000 Так, смотри, а 1.000 новых пользователей вмест. А сколько у нас вообще пользователей?
Speaker A
Ну вот нам, скажем, момент начала этой задачи. Ну пускай будет с тысячи и мы будем расти. То есть начинаем условно с нуля, и каждый месяц у нас прирастает по 1ты000 пользователей.
Speaker A
Угу. О'кей. А, но да, тогда большого смысла разносить э регистрацию авторизацию наверное нет. А так, ну разве что мы можем, а мы можем разнести так, но да, мы если ну хотя, блин, это несерьёзная нагрузка. Ладно. Аа я хотел
Speaker A
сказать про то, что с там когда-то через энное количество времени с ростом нагрузки мы аэ ну так тяжело как бы разнести авторизацию и регистрацию, да, потому что это всё про пользовские данные так или иначе, то мы бы могли
Speaker A
разнести здесь, допустим, на две реплики, там одно, а, там мастер и другое какой-нибудь, например, а синхронный слайв, предположим, да. Вот.
Speaker A
Угу. Но, ну, как бы сейчас это кажется оверхедом сильным. 20. Ну, ты разносить про разнос имеешь в виду на уровне опять же слоя хранения данных или на уровне прикладного слоя?
Speaker A
То есть сам сервис самих сервисов, то есть сервис регистрации и сервис авторизации. Ненене на на уровне хранения данных. То есть условно то, что регистрация у нас будет, ээ, как запись проходить, допустим, в мастер, да, а авторизация через ну как по сути чтение, да, через
Speaker A
асинхронную реплику. Угу, я понял. Ну о'кей, ладно, пока можно в это не укапываться, но хороший ход мысли.
Speaker A
Вот. А так дальше у нас userсервис, значит, который при регистрации, но м при регистрации, да, с учётом того, что мы закладываемся на расширение и, ну, предположим, да, что у нас не только новые каналы сообщений могут появиться, но и новые типы сообщений. Оп. Так,
Speaker A
новые типы сообщений, то а логично было бы сделать некий сервис а сервис агрегатор, да блин агрегатор.
Speaker A
Так, сейчас, да, торт. Вот. А-а, в чём смысл, да, что у нас, если появляется здесь ещё один, ещё один сервис, который генерит там, ну, какие-то сообщения, то мы можем их, э, все сливать в сервис агрегатор. Опять же у нас может
Speaker A
здесь рядышком появиться, допустим, а, там, я не знаю, settings, да, какой-нибудь сервис, который хранит в себе пользовательские настройки то что допустим хочу получать уведомления на имейла, но не хочу получать эсэмэски.
Speaker A
что-нибудь такое. Соответственно, тогда подобный сервис агрегатор. Сейчас, секунду, просто немного горло болит, поэтому вот.
Speaker A
А значит, Угу. А сервис агрегатора будет собирать, ну, давай просто, чтобы так для наглядности ещё было. А собирать, причём собирать, да, тоже важный момент, раз уж мы всё правильно делаем. Собирать, конечно, через топики, ну, в смысле, асинхронно.
Speaker A
Прости. Значит, асинхронно собирать все события, а потом, а, дообогащать, значит, свою информацию настройками на атификации и хранить в себя, скажем, некую историчность, какие, э, уведомления какому пользователю были отправлены, по какому каналу. Вот. И дальше, соответственно, у нас идёт ещё
Speaker A
один топик. И после чего у нас ну в данном случае будет некий, а, email gitway да блин email gway. Вот. А, соответственно, для чего? для того, чтобы когда у нас появится там SMS gitway, да, там, я не знаю, PH gitway, там что-нибудь ещё,
Speaker A
WhatsApp Telegram ну короче вот то на каждый гейт у нас, э, ну, соответственно, точнее, на каждый канал связи у нас будет отдельный гейт, потому что а соответственно каждый канал связи у нас может быть абсолютно отдельный провайдер. Вот. И дальше здесь
Speaker A
у нас уже, э, собственно, торчит некий провайдер. В да, в нашем случае это email, да, провайдер, вот, а которому уже email gitway, ну, допустим, там, к апе которого он обращается. И дальше здесь ещё, если мы совсем это по-правильному
Speaker A
делаем то а мы сделаем inпиic и out to так как мы должны, ну, допустим, если, не знаю, провайдер пятисотит, да, или там что-то ещё не получилось, то мы должны как-то обратно м ну получить информацию о том, что а
Speaker A
вот конкретно email, да, такому-то пользователю мы не смогли отправить. И, соответственно, эту инфом сервис Агрегатор в историчность, ну, в исторические наши данные. Вот сервис Агрегатор, он какую функцию выполняет? Напомни, пожалуйста.
Speaker A
А сервис-агрегатор в данном случае выполняет функцию, собственно, агрегации всех уведомлений, да? Ну, то есть, ну, то есть это некий сервис уведомлений да получается.
Speaker A
Мм, не совсем. Это скорее сервис, о, маршрутизатор, что ли, если можно так сказать. Ну, то есть он собирает в себе все уведомления, а, мапит их на каналы того или иного пользователя и распределяет, э, сообщения по, ну, по топикам, а-э, того или иного гита для
Speaker A
отправки по тому или иному каналу сообщений. Угу. Вот. А, смотри, у тебя у сообщений может быть ну какая-то аля темплейты, ну, то есть какие-то шаблоны сообщений, собственно, с которыми вот в этот агрегаторы должны будут прилетать у тебя сообщения из
Speaker A
разных каналов. Ну, ну, как каналов, я имею в виду, из разных сервисов по разным там темам.
Speaker A
Угу. Да. Где где вот эта вот конфигурация должна храниться того, какие там темплейты условно, какие у них обязательные параметры, что в них?
Speaker A
А так, да, проте мплейт - это хороший момент, если А, слушай, ну, безусловно, можно это вынести в отдельный А, ну да, кстати, проиication settings. Я что-то погрячился. У нас же 1.000 пользователей в месяц, да? То есть поначалу мы можем
Speaker A
вообще какой-то, я не знаю, inмеory config сделать, чтобы, ну, не пладить лишнюю нагрузку на сеть. Вот это.
Speaker A
Угу. Вспомнил. Значит, по поводу а шаблонов. То есть ты имеешь в виду, что от сервисов источников мы получаем какие-то данные, а из там некого источника шаблонов мы получаем, ну, собственно, некийте темплейт, в которые эти данные нужно засунуть, правильно?
Speaker A
Ну, то есть как у тебя сервис, да, будет понимать, какое именно сообщение необходимо пользователям отправлять, условно вот у тебя сегодня приветственное письмо добавляется, а завтра будет добавляться какой-нибудь ещё тип сообщения, которое там с другим текстом. Вот эта информация о том, что
Speaker A
именно использовать, какую текстовку и так далее, она где, на чьей стороне должна храниться здесь, в этой схеме.
Speaker A
Так. А угу, сейчас сейчас сейчас сейчас. Ну, ну можно предположить, что, значит, сервисы источники, да, они отправляют тип уведомления, а по этому типу мы можем мапиться на конкретный мплейт.
Speaker A
А, ну у тебя же для определённого типа можно несколько тимплейтов задать. Логично, что ты можешь там разные текстовки, SMS там условные и содержание их там и может быть какие-то атачменты, ну, не смски, а, допустим, письменные электронны отправлять с, ну, условно, по одному каналу email.
Speaker A
Ну, не совсем тебя понял. Я имел в виду то, что, э, допустим, если мы отправляем, ну, вот отсюда, да, аа какое-то сообщение с типом то, что там приветственный email, то, ну, под приветственный email у нас только, а ты
Speaker A
имеешь в виду то, что, ну, там в разное время у нас может быть несколько темплейтов на тип приветственный ail, да?
Speaker A
Ненене, ну, не в разное время, а у тебя, допустим, у тебя канал связи сейчас email, да, с пользователями. И для пользователей мы глобально можем отправлять приветственные письма. Вот сейчас потом ты можешь отправлять ещё, ну, не только приветственные письма,
Speaker A
какие-нибудь там поздравления с днём рождения пользователем, ещё что-нибудь такое. И это уже будет другой как бы тимплей фактически, потому что там другой другая текстовка будет. Перемены те же самые остаются, условно там, ну, какой-нибудь там логин пользователя усложн. Вот. Хотя перемены тоже меняться
Speaker A
могут отплей до тим плейт. Вот. И где вот эта информация о разных тимлейтах должна храниться? [смех] У тебя вот сервис Ага. который вот, допустим, сервис, который у тебя, он сейчас должен вызвать сервис агрегатор.
Speaker A
Что он тебе должен, как его вызвать, что он ему передать должен, какое сообщение, чтобы коммуникация произошла с пользовая.
Speaker A
Ну, смотри, мне кажется, что в данном случае в данном случае корректнее было бы темплейта хранить на стороне а или сервиса агрегатора. Опять же, ну, так как тимплейтов, допустим, у нас поначалу немного, то это тоже может быть какой-то, а,
Speaker A
ну, ладно, может быть уже не in memory config, но тем не менее. или же, э, допустим, где-то в отдельном template сервис, а, в отдельном сервисе, да, который пока уберу, соответственно, к которому, ну, вот тут тоже момент, предположим, да, приходит к нам сообщение, и если мы
Speaker A
будем ходить синхронно к такому темплей сервису, то это, ну, получится фигня, потому что сразу нагрузки мы просто положим эту историю. Если мы начнём проливать, допустим, каждый новый мплейт в сервис Агрегатор, тогда, ну, получится дублирование информации.
Speaker A
Так, если мы если мы предположим, не нужен нам здесь template сервис, если мы предположим, что мы на уровне usрсервиса начинаем, уже знаем, какой именно темплейт нам нужен, то то это размывание контекста, потому что у нас здесь пользовательские данные и за каким-то лешем ещё, а,
Speaker A
темплей уведомлений, что тоже нехорошо. Поэтому, поэтому м или же мы можем, а, воспользоваться антипаттерном и всё-таки небольшую логику на гейт засунуть. То есть в самый последний момент а да, заиспользовать какой-то темплейт где-то здесь.
Speaker A
Слушай, ну выглядит так, что а чтобы не платить лишнюю нагрузку, то информация о темплейтах должна быть или на сервисе агрегаторе, или на гейтах. Вот. Но с точки зрения того, что на гитах вообще, ну, по-хорошему, никакой логики не должно быть, да, то получается, что
Speaker A
остаётся так сервис-агрегатор. Ну, как бы получается, что так. Ну, вот сервис агрегатор, ты его так интересно назвал. А история всех коммуникаций, она где у тебя храниться будет в базе какого сервиса?
Speaker A
А вот здесь в Ну да, тут, наверное, просто на а конфигурить, если тебе нужно будет на фронте потом завести какие-нибудь ручки для того, чтобы листовые ручки, для того, чтобы конфигурить шаблоны каких-нибудь сообщений, да, вот тот же самый приветственное сообщение, тебе
Speaker A
нужно будет сконфигурить потом, чтобы отправлялось там не один текст, а другой текст. На стороне какого сервиса ты бы эти ручки выставил?
Speaker A
То есть, по сути, конфигурирование темплейтов, да? Ну, если мы темплейты храним вот здесь в сервисе агрегаторе, то и ручки будут тоже здесь.
Speaker A
Угу. Угу. Ну, я к тому, что сервис агрегатор - это фактически какой-то сервис уведомлений. У тебя он у тебя агрегатором называется только потому, что, я так понимаю, он агрегирует каналы связи у тебя или агрегирует сообщения от всех мест. Но
Speaker A
как бы сервис уведомлений на то он и агрегирует их, потому что он сервис уведомлений, все к нему стучатся.
Speaker A
Да. Ага. А вот историю дальше, если развивать с тем, что у нас ээссервис какое-то время доступен, вот ты выделил два топика и наутопик, как ты их использовать будешь? Какую механику будешь реализовывать для того, чтобы, ну, в случае, если сервис email сервер
Speaker A
не доступент в течение код времени? Да. Но если мы получили отлу, ну, естественно, те мы заложим какую-то стратегию повторов, да? А если мы там в результате, ну, сколько там обычно, ну, пять-7, наверное, по-моему, запросов там с увеличившимися интервалами, да,
Speaker A
закладывают. Ну, короче, по если мы в результате последнего запроса, серии запросов ничего не получили, да, получили ошибку, то а мы отправляем сообщение в outтопик о том, что такой email с таким идентификатором там под, ну, короче, весь скоп атрибутивный
Speaker A
состав, да, по этому объекту не был отправлен. Ну и по возможности, если там email провайдеры такое поддерживает, то, а, с какой-то более-менее осмысленной ошибкой, что не просто мы не смогли, да, а почему не смогли, там провайдер прилёг или там пользователя нет или email
Speaker A
неправильно указан, м там или email не существует. Ну, короче, да. Угу. После чего это сообщение, а, значит, учитывается, ну, давай назовём его тогда нафиication севис, чтобы он нас не смущал. А, notification сервисом. И получается, обновляется запись, которую мы уже
Speaker A
записали в базу сервиса нотификации, то есть о том, что сообщение, допустим, а было отправлено, но но не доставлено.
Speaker A
Вот типа такого. То есть, ну, просто поменяем статус на то, что оно зафрейлилось. Вот. И, соответственно, если нам нужен будет какой-то отчётик, дашбордик там где-то на фронте о том, какие уведомления там кому когда были отправлены и через какие каналы, то вот
Speaker A
у нас получается здесь как раз готовый набор данных для А как мы будем понимать, что коммуникация произошла всё-таки и что, ну, я так понимаю, такую-то статусную модель вводишь у нотификации, что она там по статусу прошла условно. Да, да,
Speaker A
да, конечно. Ну, то есть должна быть статусная модель, что а там она создана, допустим, а отправлена и там, предположим, доставлена. То есть, а, в случае, ну, в хэппи пасе, да, когда мы всё-таки отправили email провайдер, он нам отдаёт
Speaker A
200, и мы точно так же, а, ну, там, я не знаю, 2011, да, ну, короче, то, что всё успешно, то мы успешный результат точно также отправляем через outopic notification service и, собственно, обновляем запись от, ну, ту запись, короче, которую мы только что отправили.
Speaker A
Вот что она была доставлена, там всё о'кей. То есть, ну, какой-то терминальный, финальный статус, да? Угу. Угу. О'кей. Good. А насколько с авторизацией ты знаком вообще? Знаешь ли, ну, тут так в сторону немножко вопрос такой: э что такое токены и зачем
Speaker A
они нужны вообще? А, ну смотри, насколько я помню, если мы говорим про Birрер токены, то это аа просто рандомная строка. Ну, как рандомно, она генерится типа, а по Так, сорри, у меня наушник пропилил. А, да, значит, это более-менее рандомная
Speaker A
строка, которая не содержит в себе никакого, э, собственно, контекста. Если мы говорим про GVT token, то GVT token, как правило, содержит в себе скоe. То есть это идентификатор пользователя, это там дата выдачи, то есть там дата создания, дата экспирации этого токена.
Speaker A
Ну и ещё какой-то атрибутивный состав, там, например, для rollbased accessмодели или там, если кто-то заморочился, то для attribute based access модели. Ну, то есть, э, какая-то информация, короче, которая нам нужна для разграничения прав доступа пользователя. Вот.
Speaker A
А что за accessрили токены? А, ну, соответственно, access toкеen а это как раз токен, который ты получаешь при, э, скажем, первом взаимодействии, да, с сайтом. А при там ты вводишь креду. Ну, если мы говорим, да, про какую-то базовую аутентификацию, ты
Speaker A
вводишь свои креды, ты получаешь токен в ответ. Вот. а-а, refresh token, соответственно, выдаётся тебе, ну, по-хорошему, он выдаётся тебе, аэ, ну тут по-моему есть ээ два варианта. Или ты обращаешься со своим accessтокеном на просто отдельную ручку и получаешь рефреш. Ну или, по-хорошему,
Speaker A
тебе рефреш должны сразу выдавать вместе с accс-то токеном. Вот. А, ну, соответственно, рефреш токен тебе нужен для того, чтобы просто продлять сессию и тебя не разлогинило. Ну, потому что у accс токена как бы там сколько, одна-д минуты, по-моему. Срок жизни. Ну,
Speaker A
примерно. А почему палате? А в целях безопасности, чтобы даже если твой токен угонят, да, то не могли. Ну, у злоумышленников было бы крайне ограниченное время на там совершение своих злодейских поступков.
Speaker A
Угу. Д. Хорошо. Так, а покажи, можешь удалить схемку ещё раз посмотри, что у нас получилось тут.
Speaker A
Ну, как-то так. У меня, по-моему, ничего не отдалилось даже. У тебя изменилось что-то? А, вот сейчас есть. Да.
Speaker A
Ага. О'кей. Ну и вот тут как бы, да, внешний прояр. Ага. О'кей. Так, давай пойдём потихоньку дальше.
Speaker A
Смотри, про архитектуру мы с тобой достаточно поговорили. В принципе, я перестаю шарить, да? Да. Нет, не перестаёшь.
Speaker A
А потому что по бать данных сейчас будет дальше небольшое задание. А, всё, понял. Ага.
Speaker A
Смотри, мы сделаем, нам нужно будет, э, сделать небольшую ердишку. А какой кейс у нас? Кейс у нас оффлайн кинотеатр, то есть кинотеатр физически, который мы можем прийти, купить билеты на интересующий нас фильм, посмотреть. У нас один кинотеатр, у нас только
Speaker A
открывается наша будущая сеть. Она состоит из одного кинотеатра в вашем в твоём городе, условно. Вот и всё. Собственно, нам нужны основные сущности здесь отобразить, которые реализуют этот процесс.
Speaker A
сильно в атрибутивный состав давай не будем укапываться. От тебя главные сущности, основные атрибуты для того, чтобы погреть основные процессы. Вот. И и связи между ними.
Speaker A
Угу. О'кей. А так, ну опять же, если мы говорим то, что у нас сеть, ну, предполагается, да, то есть мы как бы, да, пока один кинотеатр, но тем не менее то, а первый, наверное, объект это у нас будет синема,
Speaker A
да? А, соответственно, это смотри, а в одном кинотеатре сколько залов? Ну, пусть будет четыре зала.
Speaker A
Четыре зала. А, соответственно, у нас будет у нас будет как зовуто синема хол можно назвать новыйхо, да?
Speaker A
А синимахл а у нас будет а сеанс, да, который у нас показывает в синему холле.
Speaker A
Так, сеанс типа. Ну нет, не в как фильм. Ну давай фильм в пусть будет. Ладно.
Speaker A
Угу. Не знаю. Боле может быть. Ну давай. Да. Да. Кстати, сн дажено суть. Понятно.
Speaker A
Угу. Так. А значит, в зале есть у нас места. Так, в зале есть места. Сейчас, сейчас, сейчас.
Speaker A
Мм, да, места есть, но сами по себе места нам не интересны. Нам интересны места в контексте, э, сеанса фильма.
Speaker A
Значит, у нас должны быть сейчас а у нас должны быть букинги, да? Так и тактактак. Букинги, букинги, значит.
Speaker A
Сейчас, э, думаю, где нам хранить свободные места. Так, тогда всё-таки нет. Нам нужны отдельно справочные справочная информация ол, ну, я не знаю, там places пусть будет, да. И а в рамках сеанса фильмов, а, допустим, session free places, что-то такое. И у нас здесь
Speaker A
будут получается сеанса, адишник места и его статус. Да, нормально. Так, Bings. Аэ, это значит Booking у нас будет идентификатор а-а сеанса идентификатор. Так, а смотри, у нас А, ну да, у нас же офлайн кинотеатр, значит, никаких пользователей у нас нет. У нас есть просто, ну, как
Speaker A
даже даже не бронь, по сути, а, а, ну, вот, кстати, давай вопрос. А мы раз, ну, хотя, по-моему, в Алфан кинотеатрах такого нет. Функционал брони у нас должен быть или просто пришёл и купил? То есть никаких там промежуточных
Speaker A
состояний. Брони, брони. Давай просто пока пришёл, купил по факту. Угу. Ну давай тогда. Ну не, а, ну тикетс. Вот тикет. Нормально. Значит, в тикетах у нас будет ID сеанса.
Speaker A
ID место и ну стоимость например что-нибудь такое. Так, ну, ну, давай так. Ты говоришь атрибуты накидать или, ну, так, минимальный какой-то набор, да?
Speaker A
Минимальный набор, да, для того, чтобы понятно было. О'кей. Так, это мы удаляем ID. А.
Speaker A
адрес адрес на здесь можно си так упс и например чтото такое ну здесь соответственно может быть у нас чисто справочек какой-то сити А там в регионы упарываться не будем.
Speaker A
Угу. А так, ну, соответственно, один кинозал у нас может быть в одном городе. А в одном городе у нас может быть много кинозалов.
Speaker A
А, поэтому, а, значит, у нас будет связь один ко многим. Давай сильно пока не будем в связи уходить. Достаточно словами расскажешь и я, в принципе, чекну слова.
Speaker A
Да, ну получается в одном городе может быть, а может и не быть там кинозал, да?
Speaker A
Ну то есть мы там не открываемся ещё, а один кинозал может быть только в одном городе. То есть, соответственно, здесь э-э будет строго один к не обязательно многим. Угу.
Speaker A
Вот. А дальше поехали. Здесь симахол получается у нас точно так же. ID. А так ну какой-нибудь number, ну или тут давай, давай name лучше, да. Name этого зала. И, ну, чисто справочная, например, вместимость там по сети пусть будет.
Speaker A
А, ну и да, [смех] значит, и а синема ID, да. Ну так, ну да.
Speaker A
М, получается так. Соответственно, мм, в одном, ну, один зал может быть строго в одном кинцентре, поэтому здесь обязательно ну строго один к одному или многим, да? То есть ну кинотеатр не может существовать вообще без зала, соответственно, хотя бы
Speaker A
из одного зала должен, ну, состоять, да? То есть, соответственно, один зал или несколько. У. Угу.
Speaker A
А так дальше. Hle places. Э-э, ну не знаю, я везде по привычке ставлю просто синтетический ID, поэтому не обращаю на это внимание. Угу.
Speaker A
Значит, здесь у нас будет, ээ, call id. Здесь будет, собственно, row number и, а, place number, ну, или sheet number.
Speaker A
She seat number, наверное, даже. Правильно. Угу. Вот, значит, здесь у нас ВК, а так. И это у нас уходит сюда.
Speaker A
Соответственно, одно место может быть только в одном зале, да? А в одном зале, ну, точно одно или несколько мест должно быть, даже если какой-нибудь вип-зал.
Speaker A
У. А. Угу. Так, дальше, значит, филм. А, так, сейчас сейчас сейчас. Слушай, ну тут может быть ещё, наверное, знаешь справочная ну да, вообще хорошо бы её сделать.
Speaker A
Справочная история видим в виде, а какие фильмы у нас вообще есть, ну в плане физическом, да, то есть какие бобины есть конкретно в этом кинотеатре. Вот типа фильм там, ну, ну не знаю, фильм Warхаус пусть будет. А значит,
Speaker A
ID а пок. Так, это мы выбираем. здесь. Ну, тут, соответственно, уже можно разные атрибуты, да, придумать для фильма.
Speaker A
Дишник пока достаточно. О'кей, да, я понял, что там и Синема ID, соответственно, ну, тот кинотеатр, где вообще у нас он имеется.
Speaker A
А вообще, по-хорошему для таких табличек с класскими остатками ещё пишут, собственно, само значение остатка, да.
Speaker A
Вот. Но вряд ли, наверное, несколько. А, ну хотя если в разных залах показывать, вот я, конечно, тут не очень знаю, как это устроено в кинтере. Давай лучше я добавлю. А, типа амаountут. Ну, вдруг у нас какой-то супер аускульный зал, да,
Speaker A
где вот один фильм, одна бобина. Если ты хочешь в двух залах показывать, пожалуйста, две бобины. Значит, э у нас уходит вот сюда.
Speaker A
Ну, тут получается, что что А так подожди подожди. Да, тут я наврал. А здесь у нас будет, а здесь у это смешал две таблички. Здесь у нас будет как раз вот фильм анима, потому что у нас отношения многие ко
Speaker A
многим. А значит, это я отсюда убираю. И это я убираю. Вот. А здесь у нас получается свой ID. А здесь фильм ID здесь, да? Вот так. И вот так, да, вот так будет правильно. А значит, синем ID у нас уходит сюда,
Speaker A
а ID у нас вот сюда. Вот здесь получается что? что а у одного кинотеатра здесь может быть несколько записей, то есть несколько а разных фильмов, да, с каким-то количеством ну этих фильмов физически, да, лент. Вот. А здесь у одного фильма,
Speaker A
соответственно, может быть, ээ там несколько копий в разных кинотеатрах. Угу. Ну, стандартный как бы один. Ой, многие ко многим. Вот. А дальше поехали.
Speaker A
Значит, фильм session. Здесь мы так, ну, начинаем с самого простого. А пока это выбираем. Мм, значит, а здесь start end анема ID.
Speaker A
И так. И вот здесь это интересный момент, но вообще фильм синема получается ID. Фильм синема ID.
Speaker A
Ака, пока знать так. Ну, я не знаю, но можно ещё ради интереса добавить просто какой-нибудь статус, если там у нас sold out, чтобы мы могли написать soldout красивенько.
Speaker A
[смех] Вот. Ну, типа, чтобы не агрегировать это по там фриплейсам. Угу. А здесь, значит, у нас мы идём сюда.
Speaker A
Здесь мы идём. Блин некрасиво. Так, не сюда, а вот сюда. Вот так вот. Получается что а один сеанс а может ити строго в одном зале, да, в одном зале может быть в разное время, что справедливо, разные сеансы получается здесь опять же строго
Speaker A
один к а не оббязательно многим, да, потому что в зале, ну, я не знаю, зал может быть на ремонте там, я не знаю, а, ну, короче, не проходит там ни один сеанс. Вот. А-а, значит здесь будет в одном сеансе ровно один фильм.
Speaker A
А один фильм может быть в разных сеансах, да. У что здесь будет а-а так сейчас, э, один фильм в разных сеансах. Значит, здесь будет, э, не оббязательно многие, а здесь у нас будет строго один, да? То есть он сеанса строго один фильм, да?
Speaker A
Всё правильно. А дальше аэ здесь у нас что? То же самое ID пока. Так, а тикетс получается здесь нам важно filmм session ID.
Speaker A
Аэ так. H place id, да? Ну, то есть на какое место там человек купил билет и м, ну, прайс, наверное, в общем-то, больше в тикете нам ничего как будто и не не надо.
Speaker A
Так, значит, здесь у нас film session входит вот сюда, аplй у нас уходит вот сюда. То есть получается, что в одном один билет, э, может быть на, ну, только на одно место, что характерно, а, ну, на одном месте может
Speaker A
быть в разные моменты как бы разные билеты, да? То есть получается здесь один к аэ ну о'кей, к не обязательно многим, да?
Speaker A
Ну, то есть, если мы вдруг только открыли зал и там ещё ни одного сеанса не было, то, соответственно, местом на месте может не быть ещё ни одного билета.
Speaker A
Вот. А с точки зрения, значит, сеансов, в одном билете один сеанс. Ну, если мы говорим: "О'кей, давай про простые билеты, да, там без мультисеансов, без билетов на всю ночь и так далее". Вот. Аа, значит, в одном сеансе, соответственно,
Speaker A
может быть много билетов или не одного. А, то есть здесь, соответственно, точно та же связь строго один к не обязательно многим.
Speaker A
Угу. А так и здесь session frees получается у нас опять ID. А, а вот вот эта табличка, она тебе точно нужна?
Speaker A
Да. Слушай, да на самом деле она, да, она спорная. Почему? Потому что у нас есть, э, ну, как бы знание всех мест на всех рядах в зале. И, в принципе, из тикета мы можем как бы понять, кто из них, э, уже, ну,
Speaker A
занят. Вот. как будто бы, да, тут, наверное, знаешь, э-э, просто потребуется, ну, несколько джойнов, да, чтобы, ну, вот условно представить, да, вот этот классический экран, э, когда ты приходишь в зал, ну, в смысле, в кинотеатр и видишь там вот этот экран,
Speaker A
схема зала и вот там вот эти вот заняты, а вот эти свободные. Вот. И вот для такого запроса можно было бы как будто вот отдельную табличку сделать. Ну, просто как, знаешь, готовую аля витринку. Вот. Хотя я согласен, что в
Speaker A
принципе она излишняя. Угу. Ну тебе эту витринку, да, всё время придётся актуально её тут поддерживать постоянно здесь данные.
Speaker A
Она у тебя забиваться будет дропать её, возможно, данные оттуда. Ну да, да, да, определённо. И, ну, в принципе, да, тут и нагрузка получается, что мы при каждой, а, записи создания тикетов, да, мы должны будем ещё апдейтить session places. Угу.
Speaker A
При окончании получается сеанса, э, мы должны будем Не, ну слушай, не обязательно дропать, можно там просто проставлять статус, ээ, и триггериться на статус, что типа вот с таким статусом мы не смотрим, но да, она будет раздуваться. Аа, соответственно,
Speaker A
нам надо будет вот тут на нам надо будет уже просто с каким-то статусом там через какое-то время сносить лишние записи, потому что они будут замусориваться. Ну, короче, да, такая спорная штука.
Speaker A
Угу. Угу. Вот. А так в остальном вроде как будто бы Ну, как будто всё.
Speaker A
Угу. Ну, я тут, правда, местами начал отмечать обязательность полей вот жирным, но потом забил. Извините.
Speaker A
Угу. Не, ничего, да, для ускорения времени, в принципе, это не обязательно было. И тем более, я бы сказал, а по базам скажи ещё такой вопрос. Что такое шардирование и можешь ли рассказать, как можно джой шардированный бач сделать?
Speaker A
А шардир, ну, по сути, это, а, это партизационирование на разных железках, ну, в смысле, на разных серваках, да? То есть, а, условно, если ты просто потеционируешь какую-то, ну, таблицу разбиваешь на партиции в рамках одного сервиса сервера, да, то как бы
Speaker A
это одна история попроще шардирование, когда ты разные куски таблиц, ну, условно таблицы, да, закидываешь на разные сервера. Вот. А-а как не можно коннектиться? А, слушай, ну, определяется ключ шардирования, собственно, по которому вообще бьются да бьётся таблица. Вот дальше, честно
Speaker A
говоря, сейчас я читал про это, но сходу не вспомню. Хочется сказать про LinkedI сервер. Хотя в то же время кажется, что это не большой оверхad для шардирования, и можно это делать как-то проще. Мм, сходу не вспомню сейчас.
Speaker A
Угу. О'кей. Ну ничего. Ну, то есть я не думаю, что там что-то минимум, да, как минимум ДБИнки есть. Если имел с ними дело, то они здесь помогут.
Speaker A
Ну, под Да, подболинком я как раз имел в виду LinkedIn сервер. То есть Угу.
Speaker A
в MSсQLэле он, по-моему, так называется. А ты с какими базами чаще работал? А, ну вот в самокате последние, получается 3 года с Постгросом. А до этого, а до этого в альфе там вообще бог знает, что было. Там обска Equation была
Speaker A
в качестве базы. Вот. А до альфы Ну о'кей, в альфа там ещё была манга, но манга для каких-то суперспецифичных задач. А до альфа ВТБ ээ там было M SQL.
Speaker A
Вот как раз. Угу, я понял. Так, ну ладно. Смотри, по основной части технического собеседования мы прошлись немножко, на самом деле, вывалили за тайминг, но побольше поговорили по архитектуру. Мне кажется, это это важно.
Speaker A
M.
Topics:системный аналитиксобеседованиетрассировка требованийсистемная аналитикаархитектурасагимикросервисытребованияпроектирование системIT-карьера
