Архитектура Пет-Проекта Для Получения Работы Без Опыта — Transcript

I developed a complete architecture for your PD project, which includes microservices, Kafka, Redis, Amazon S3, and more. Now, I will sequentially explain how to move from this to that. I will explain how to apply all the technologies for different project features and, most importantly, make it ready for really high loads. After watching, you will take something like this, and your resume will blow employers' minds.

реально высоким нагрузкам после просмотра ты заберёшь такой себе и твоё резюме снесёт крышечку работодателям Привет меня Влад зовут Я работаю программистом на бэнде уже 8 лет а прямо сейчас в одной из лучших компаний в мире и живу в дами на своём канале

Hi, my name is Vlad. I have been working as a backend programmer for 8 years, currently at one of the best companies in the world, and I live in Dami. On my channel, I talk about how you can become a super powerful programmer.

нагрузками есть куча приложений которые ежедневно получают огромные нагрузки и на крутом стеке Twitter Telegram и airbnb каких только нет Так зачем выдумывать своё сделаем их Клон решим их реальные задачи и тогда работодатели увидят что мы можем делать настоящие

Which application to choose for your PD project? Our goal is to show the employer that we are the best, which means we need a system that demonstrates your ability to work with a modern stack and handle high loads. There are plenty of applications that receive huge loads daily and run on cool stacks like Twitter, Telegram, and Airbnb—there are all kinds.

влево А если человек тоже свайпнуть тебя вправо то у вас мэтч совпадение и вы можете чатиться теперь звучит просто но это одна из самых высоконагруженных систем в tinder 80 млн юзеров 7 млрд лайков в день а значит десятки

So why invent your own? Let's make their clone, solve their real problems, and then employers will see that we can create real features. After all, they use these themselves every day. So we take an application everyone knows and that has a lot of users, for example, Tinder. It's a dating app where you register everything and can browse other users. If you like someone, you swipe right; if not, swipe left. And if the other person also swipes right on you, then you have a match and can chat.

где живёшь какие увлечения и прочее и конечно нужно добавить фотки это важнейшая часть tinder именно по ним пользователи делают свайпы и решают кто им нравится плюс юзеры определяют кого и где Они ищут пол возраст в каком радиусе От текущего местоположения можно задать

Now it sounds simple, but this is one of the most heavily loaded systems. Tinder has 80 million users, 7 billion likes per day, which means tens of billions of swipes. Each swipe is a request to the backend. Imagine how many requests hit there every second. The architecture must be really great, and that is exactly what we will build.

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

We choose features that are under high load. In Tinder, you can create a profile with your data: name, where you live, hobbies, and so on. Of course, you need to add photos. This is the most important part of Tinder because users make swipes based on photos and decide who they like. Plus, users specify whom and where they are looking for: gender, age, and radius from their current location. You can set a radius of 30 km, and only those nearby will appear. If you travel to another city, profiles from there will show up. Therefore, geolocation is one of Tinder's key features.

мы получим по-настоящему мощное приложение но ты будешь чётко знать Зачем чем там каждый компонент Итак юзер может создавать профиль со всеми своими данными и фотками а также добавить свои предпочтения для поиска других юзеров кажется что всё должно быть просто и что

There is also a deck of user profiles that you can scroll through. This deck must load very quickly and always match the user's preferences. Soon, we will learn how to load it literally in milliseconds, even for millions of users. When you swipe right on someone, you both get a notification. This is the most important feature. It seems like it can be done very simply, but you will see that it is much more interesting.

когда внутри приложения есть три класса контроллер сервис и dao Data Access object ещё называют репозиторием у каждого из них особая роль задача класса контроллера описывать rest AP делать проверку данных полученных от юзеров и формировать ответ с результатом выполнения операций rest AP - это набор

For each feature, I will first consider a naive architecture, like a beginner would do, then show its problems and try to improve it so it can handle really high loads. With each step, the architecture will become more complex, and in the end, we will have a truly powerful application. But you will clearly understand why and what each component does.

так вызывать и есть rest приложения и Наверное ты уже слышал и про контроллеры и про rest и про http но не хватало объяснения простыми словами специально для начинающих джави Я в прямом эфире провожу бесплатный трёхдневный интенсив по фреймворк springing и разработки

So, a user can create a profile with all their data and photos, as well as add preferences for searching other users. It seems everything should be simple, and what a beginner would do is write a backend with CRUD operations, for example, in Java, add a database like PostgreSQL, where everything is stored. From this backend, SQL queries would be sent to insert, retrieve, and update data.

его часть и буду прямо писать код в прямом эфире все темы рассмотрим с крутыми анимациями и крайне простыми словами на жизненных примерах после интенсива ты не только сможешь писать собственные веб-приложения но заберёшь моё и продолжишь его разработку Что

The backend can be made with a three-layer architecture, which means the application has three classes inside: controller, service, and DAO (Data Access Object), also called a repository. Each has a special role. The controller's task is to describe REST APIs, validate data received from users, and form a response with the operation result.

контроллера уже передают полученные данные в класс сервис который выполняет основную логику приложения именно здесь пишется алгоритм структурирующий данные для сохранения в базу например Зачем нужен отдельный класс и почему нельзя всё в контроллере написать просто чтобы всё не было в куче контроллер содержит

REST API is a set of functions of such a class that can be called not only from code, as we are used to, but also over the internet. That is, you literally write the required URL in the browser, press Enter, and bam, the function in the controller class is executed. Here is a list of all functions that can be called this way, and these are REST applications.

котором она запущена а потом получать её обратно Когда нужно значит из нашей программы бэнда надо как-то подключиться к другой программе базе данных чтобы передать туда информацию которую мы получили от юзеров по интернетом и вот как раз для этого нужен класс dao в нём

You have probably heard about controllers, REST, and HTTP, but lacked a simple explanation for beginners in Java. I conduct a free three-day live intensive on the Spring framework and web application development on it. On the first day, we cover the basics: Spring beans, application context, dependency injection. On the second day, we build a web application on Spring with annotations and Spring AOP. On the third day, we practice together and write our own web application on Spring, even with artificial intelligence. I will show every part and write code live.

в dao а он уже подставляет их в Иско запрос и отправляет в базу как же устроена база данных есть таблица профиля в которой хранятся данные в том числе их геолокация долгота и широта рега профиль делаем сюда insert запрос

We will cover all topics with cool animations and very simple words using real-life examples. After the intensive, you will not only be able to write your own web applications but also take mine and continue developing it. This is much clearer than starting from scratch. The link to the intensive is in the description. Register quickly because everything will be live. You can't miss this.

фотки прямо файлами как блоп хотим получать профиль пользователя со всеми данными делаем Select в профиль и Join на остальные таблицы и вот у нас все данные и это работает Если у нас в приложении всего два пользователя которые пытаются свайпать друг друга то

So, thanks to the API, users can call our application's functions over the internet, passing data to them. The controller functions then pass the received data to the service class, which performs the main application logic. This is where the algorithm is written to structure data for saving to the database, for example.

- это просто программа запущенная на каком-то компе и на его жёстком диске она всё и хранит Но если комп с жёстким диском на 4 пиб плюс данные будут расти постоянно правило такое не храните бинарные файлы в squl базе это не

Why do we need a separate class, and why can't everything be written in the controller? Simply so that everything is not mixed up. The controller contains the code describing the REST API, and the service contains the main logic. This makes it easier to navigate later and know where everything is.

сохраним все фотокарточки Amazon S3 - это хранилище бинарных файлов текст картинки видео аудио что угодно мы арендуем его компании Amazon в Облаке и храним там сколько угодно данных чем больше у нас файлов тем больше платим за аренду дискового пространства но в

Our backend is just a program we write, and the database is also a separate program that can save information in a convenient format on the hard drive of the computer it runs on and then retrieve it when needed. So, from our backend program, we need to connect to another program, the database, to send the information we received from users over the internet.

подключается к Amazon S3 и отправляет туда этот файл тот сохраняется а в ответ S3 даёт ссылку по которой файл можно теперь скачать из хранилища Когда нужно И вот эту ссылку Мы теперь кладём в нашу базу в таблицу фоток получается что

This is exactly why we need the DAO class. It contains the logic for interacting with the database: connecting to it, the SQL queries themselves, the code for sending them, and collecting results. Again, why a separate class? So that the code for working with the database is not mixed with the main application logic.

достаточно денег а в базе мы храним ссылки текст который весит сильно меньше самих файлов А значит экономим кучу места плюс память никогда не кончится система масштабируется на любое число юзеров и фоток но вы думаете что все проблемы позади Что будет если модель

So, the service passes structured data to the DAO, which substitutes them into the SQL query and sends it to the database. How is the database arranged? There is a profile table that stores data, including geolocation: longitude and latitude. We register the profile and make an insert query here.

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

There is also a preferences table, where there is a foreign key to the profile table to understand whose preferences these are. It stores height range, gender, and search radius. There is a photos table, also with a foreign key to the profile table, since there can be many photos. Here, we store photos directly as files, like blobs.

Бразилии то ему нужно загрузить фотки модели аж из Берлина в Рио де Жанейро пикантные данные будут передаваться по кабелям проложенный по дну Атлантического океана и Это займёт кучу времени чем дальше географические юзеры и данные тем дольше будет передача А

We want to get the user's profile with all data, so we do a Select on the profile and Join with the other tables, and here we have all the data. And it works. If our application has only two users trying to swipe each other, the system is great. But this has nothing to do with reality, and here is why.

сложных вещей уверен что это вам очень помогает Поэтому если вам нравится видео то Поставьте пожалуйста лайк и подпишитесь на канал эти простые действия Дают возможность мне делать больше роликов такого класса чтобы вы учились максимально эффективно Спасибо вам что же делать юзеры делают кучу

The problem is that in a real application, there will be 80 million users. Each will upload an average of five photos of 10 MB each. That's four petabytes of data. And the SQL database is just a program running on some computer, and it stores everything on its hard drive.

оперативке эта память намного быстрее жёсткого получать данные можно за наносекунды поэтому его часто используют как кэш дополнительное хранилище куда данные буквально дублируются Из основной базы чтобы их можно было получить сильно быстрее как тогда работает один юзер идёт в базу за профилем модели получает

But if the computer has a 4-petabyte hard drive and the data keeps growing constantly, the rule is: do not store binary files in an SQL database. It does not scale, and one day it will turn into a pumpkin. It is better to add a second service class on the backend responsible for photo logic. The profile service will call this photo service when needed, and it will work with file storage, Amazon S3.

хранит всё в оперативке А значит получение данных происходит очень-очень быстро плюс нет кучи запросов в базу и она не лагает теперь Решаем проблему географии для фоток здесь можно использовать cdn Content Delivery Network переводится как сеть доставки контента это сеть компов которые стоят в

There we will store all the photo cards. Amazon S3 is a storage for binary files: text, images, video, audio, anything. We rent it from Amazon in the cloud and store as much data as we want. The more files we have, the more we pay for disk space rental, but in theory, Amazon can give us as much as we want. They have a lot of computers, so our memory will never run out.

того который находится максимально близко к ним географически ведь там есть все копии расстояние меньше загрузка быстрее И все счастливы как в итоге работает юзер загружает фотку мы кладём её в S3 а потом ещё и отправляем в cdn cdn возвращает нам ссылку на этот файл

который мы и храним в базе фоток когда юзер запрашивает фотку мы даём ему ссылку и он по ней скачивает сам файл уже с ближайшего к нему компа в cdn а S3 служит центральным источником файлов для самого cdn какой итог популярные профили

загружаются кем угодно за наносекунды даже если у вас 80 млн юзеров то ris обеспечит молниеносно скорость загрузки обычная база давно бы тут прилегла А благодаря распределению файлов по всему миру через cdn не только сами профили но и фотки самое главное в tinder

загружаются максимально быстро потому что они находятся совсем рядом с юзера в результате никому не приходится видеть спиннер загрузки на экране Где бы в мире они не находились и это по-настоящему глобальное приложение представь как отреагирует работодатель когда у тебя в

резюме будут такие фичи Да к тебе Иры сами прибегут Потому что ты умеешь делать приложение такими как в реальном мире где такому научиться Именно для этого я сделал Java bootcamp это интенсивная учебная программа где ты в команде с другими участниками под

руководством опытного разработчика из реальной it компании разрабатывает огромную социальную сеть на микросервисах как раз под высокие нагрузки всё последовательно теория супер простыми словами и с понятной графикой задачи на разработку фич приложения с постепенным повышением их сложности Где в итоге мы доходим до

разработки реально мощных архитектур например это архитектура фичи ленты новостей которую мы делаем на буткемпе и всё это с инструментами и процессами как в настоящей it компании реальный разработчик Твой ментор проверяет каждую строчку твоего кода на буткемпе оставляя комментарии Как можно его улучшить и

оптимизировать чтобы твоё приложение держало по-настоящему высокие нагрузки а также он отвечает на любые вопросы и регулярно созваниваться со всей твоей командой на проекте приходя на Java bootcamp ты попадаешь по сути на стажировку в it компании где у тебя

команда опытный техлит организация настоящей работы и самое главное проект с фичами топу уровня на самом современном стеке springboot микросервисы кавка redis и куча всего ещё регистрируйся на Java bootcamp по ссылке в описании Уже совсем скоро новый поток следующая фича - это колода

профилей открываешь tinder там стопка профилей по твоим предпочтением их можно свайпать они появляются быстро и не нужно ждать загрузки следующего свайп сразу новый и обманчиво кажется что это очень простая фича начинающие наивно делают так добавляют функцию получения стопки профилей которая вынимает из базы

предпочтение юзера а потом по ним строят сложные Сколь запрос с кучей условий на получение подходящих профилей и соответствующей таблицы Это довольно сложно придётся писать формулу расчёта попадания каждого юзера в радиус поиска но всё ещё хуже поиск по долготе и

широте будет очень-очень медленным если у нас 80 млн записей в таблице юзеров по сути нужно циклом пройтись по всем и проверить Попадает ли каждая запись в радиус Это же очень долго А запрашивать эти данные будут миллион раз в секунду и

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

сделать этот поиск быстрым есть очень хитрый способ мы можем научить базу делать быстрый поиск по геолокации у пог SQL есть расширение под названием погис которое позволяет делать геопоиск в определённом радиусе крайне Шустро там всё также хранится долгота и широта но

пост Гиз предоставляет операции поиска по радиусу по секторам Да много всяких подключаем постс к нашей базе делаем таблицу с долготой и широтой для каждого пользователя и выполняем туда запросы уже через него во всех популярных языках программирования для погис есть удобные

библиотеки чтобы делать такие вот геоза просы но Мы помним что стопка профилей должна загружаться молниеносно А тут 80 млн юзеров будут постоянно запрашивать свою стопку из базы хоть запросы теперь быстрые снова куча нагрузки на её комп и она опять превращается в тыкву Ну что

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

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

старые профили потому что из кэша читаем ерунда получается Поэтому если юзер меняет свои предпочтения или геолокацию можно удалить его кэш потому что он больше не актуален тогда запрос пользователя честно отправится в базу с postgis за новой стопкой выполнится

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

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

сначала сделать фичу свайпов чтобы ты ещё лучше разобрался с оптимизацией веб-приложений под высокие нагрузки в описании я добавил ссылку на бесплатную шпаргалку по самым популярным архитектурным решениям для миллионов юзеров эта шпаргалка лежит на моём сайте библиотека Java Junior вместе с другими

моими бесплатными шпорами там есть и по докер и по Кафки и по SQL Да куча всяких и всё бесплатно достаточно лишь зарегистрироваться на сайте и ты получишь доступ ко всей библиотеке без ограничений переходи по ссылке в описании и забирай все бесплатные

материалы у нас в tinder стопка профилей и их можно свайпать вправо Если нравится влево если нет и тоже Ну вроде совсем простая фича наивно берём наше при добавляем новую функцию для свайпа в контроллер передаём туда лак или дизлайк

True или false ID юзера которого свайпа и ID пользователя который свайпа всё сохраняем в ту же самую базу в таблицу свайпов Что может пойти не так тут на каждый свайп летит запрос в приложении по http и запрос в базу данных на

сохранение каждого свайпа если у нас 80 млн юзеров и они постоянно свайпа то комп на котором запущен Кэн быстро превратится в тыкву комп базы При таком числе запросов тоже И вот наш tinder снова лёг плюс число сохранений свайпа

будет сильно больше чем число запросов на получение колоды профилей то есть запись в базу тут происходит намного чаще чем чтение из неё получается дисбаланс одна фича даёт в 100 раз больше нагрузки чем другая но обе они находятся внутри монолитного приложения

которое запущено на одном компе тогда мы вынуждены ставить мощный комп который выдержит нагрузку и фичи свайпов и фичи колоды Но ведь колоде такой жирный сервер не нужен Но всё равно ставим его потому что свайпом то нужен а если

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

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

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

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

и это сильно дешевле но от микросервиса свайпов летит намного больше запросов в базу чем от сервиса профилей Поэтому ему можно поставить отдельную для этой базы есть варианты например No SQL база cassandra может обработать огромное число записей и это Интересный вариант

Но я всё же поставлю пос Хотя это и будет немного дороже Совсем скоро узнаете Почему выбираю её это прямо снесёт вам крышечку как тогда выглядит наивная структура этой базы есть таблица свайпов в которой две колонки ID юзера который лайкнул и ID юзера которого

лайкнули лайк вставляем запись свайп влево значит ничего не добавляем в таблицу Вроде должно работать но тут возникает наиважнейшим совпадение - это когда юзер свайпа ет другого вправо а тот свайпа ет вправо первого то есть они оба нравятся друг

другу у них совпадение в этот момент им обоим приходит уведомление вы кому-то понравились можете начинать общение как сейчас работает лайки первый юзер лайкает второго эта информация приходит в микросервис свайпов а тот идёт в свою базу и делает Ир ID первого и второго

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

таблицу но уже вставляем строчку с ID второго и первого юзеров а потом тоже Селект с обратным условием бац нашли прошлую получается совпадение но тут жёсткий подвох наша база pog SQL А значит запросы на вставку лайка и чтени обратного лайка выполняются в рамках

aset транзакций в aset есть буква I isolation свойство изоляции транзакций говорит о том что две параллельные транзакции не будут видеть незавершённые изменения друг друга Ну и что теперь может так совпасть что два юзера лайкну друг друга одновременно прямо вот в одну

и ту же секунду в этот момент в базе создаётся две параллельные транзакции с нашими запросами Пусть первая делает вставку данных успешно но ещё не успела сделать Селект в этот момент вторая тоже делает свою вставку прекрасно но теперь процессор переключается обратно на

первую транзакцию и выполняет её Селект и кажется что вот он сейчас вытащит эту строчку Что вставила вторая транзакция но нет этот запрос вернёт пустоту Как так дело в том что вторая транзакция ещё не успела завершиться Там Селект запрос

не выполнился а свойства изоляции транзакции говорит что параллельные транзакции не могут видеть незавершённые изменения друг друга и Раз уж вторая транзакция ещё не завершена то Селект из первой не увидит вот эту строчку так как это незавершённые изменение второй Ну

ладно первый Селект выполнился но завершение транзакции - это тоже отдельная операция если она ещё не отработала а процессор переключился на вторую транзакцию сделал её Селект тоже ничего не нашёл потому что результаты первой транзакции также ещё не завершены то мы теряли совпадение навсегда обе

транзакции теперь завершатся но юзеры никогда не узнают что они понравились друг другу а ведь это то зачем они вообще поставили наш тиндер катастрофа поэтому понимание эт Гарантии и многопоточности Ключевое при работе с высоконагруженные приложениями и их базами данных смотрите как изящно решить

эту проблему поменяем структуру таблицы свайпов теперь будет четыре колонки ID первого юзера ID второго решение первого И решение второго и первичный ключ будет состоять из пары этих ID свайпнуть вставку с вашими ID и ЛС для твоего решения а он тебя вправо Обновили

его решение на True в той же строчке и вот то что мы теперь храним пару свайпов в одной строчке невероятно важно Смотри внимательно сейчас будет просто взрыв мозга Теперь когда первый юзер лайкает второго то делаем insert а потом сразу

Select для проверки решений обоих на совпадение но тонкость в том что пог при вставке или обновлении любой строки автоматом вешает на неё блокировку которая не позволяет другим параллельным транзакциям с ней работать пока не завершена первая которая заблочил строчку получается Если в тот же самый

момент второй юзер лайкает первого то его транзакция на вставку или обновление данных не может начаться И ждёт до тех пор пока первая полностью завершится только в этом случае постгрес снимает блокировку со строчки и тогда вторая Может начать выполняться Но это что

значит что когда вторая транзакция начнёт выполнение то первая совершенно точно будет полностью закончена А значит мы по-любому увидим её изменение и у нас никогда не будет ситуации что мы потеряли совпадение юзеров Да такая простая Перестройка таблицы свайпов решает такую огромную проблему но

Обратите внимание насколько постгрес мощный инструмент Единственный минус этой базы тут - это то что свайпов будет много и нагрузка сюда будет огромна Поэтому её придётся шардирование выдержать но это уже другая история Ставь лайк если наберём 100.000 то сделаю ролик про шардирование а теперь

как обещал изящно устраняем дубликаты в колоде профилей когда колода формируется мы вытаскиваем профили по предпочтениям юзера из базы Но если я уже свайпа какого-то пользователя то не хочу чтобы он Снова был в моей колоде иначе скучно но Нам повезло у нас теперь есть целая

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

колоды и уже очищенную кладём в редис как и раньше опять же очень удобно что у нас SQL база для свайпов а не No SQL потому что она из коробки даёт гарантию консистентность данных и такая логика удаления повторов надёжно работает

Разумеется таких запросов поиска будет очень много поэтому в таблицу свайпов обязательно добавляем индекс который значительно ускорит запрос чтение по ID юзеров ещё более оптимальное решение - это структура данных Bloom Filter которая тоже поддерживается в pog но это уже Прямо углубленная тема для своего

проекта индекса точно хватит ну и конечно если совпадение нужно юзера послать уведомление тут используем кафку наш сервис свайпов умеет понимать когда происходит совпадение как только это случилось Он может взять информацию о таком событии ID обоих юзеров и за х

нуть их в виде Джейсона в кафку кавка - это брокер сообщений который гарантирует что всё что в него кладут будет точно доставлено на другую сторону когда эти данные там попросят У меня есть очень подробное видео простыми словами и с

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

если в приложение отправляется очень много уведомлений он будет обращаться к внешним сервисам которые предоставляет компания Apple для отправки Push уведомлений на iOS и компания Google для Android по сути мы там рега ися платим им деньги за доставку нотификаций а

потом просто из своего микросервиса посылаем в них данные через их AP и они уже как раз и доставляют пуши на нужные устройство Зачем нам тут кавка Затем что она гарантирует что сообщения точно не потеряются если бы мы отправляли данные

из одного микросервиса в другой скажем через http напрямую то к сожалению сети не надёжны и иногда возможен сбой доставки пришлось бы делать дополнительные попытки а свка удобно отправил туда и уверен что всё будет доставлено плюс свка великолепно масштабируется если мы будем посылать

очень много уведомлений в будущем не только о совпадения но и о лайках личных сообщениях и прочем то в неё будет поступать всё больше и больше данных но из-за её распределённой природы кавка может передавать в теории бесконечные объёмы информации но подробнее об этом

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

хотите такой же разбор например на архитектуру Клона Telegram А я надеюсь что это видео было очень ценным для вас будет здорово если поставите лайк подпишитесь на канал это правда помогает также Приходите в мой Telegram канал по ссылке в описании где я пишу огромное

количество стов объясняя простыми словами как и здесь сложные темы Спасибо вам и увидимся