Проектирование системы: TINDER как микросервисная архитектура

Хотите отлично пройти следующее собеседование? Попробуйте этот видеокурс по проектированию систем! 🔥
Мы проектируем архитектуру системы Tinder. Разработка этих приложений начинается с уточнения системных требований. На собеседовании к Tinder предъявляется множество требований. При проектировании системы мы будем создавать логические компоненты и определять их взаимодействие с другими сервисами на основе микросервисной архитектуры. Мы предполагаем, что любые внутренние детали могут быть реализованы с использованием наших знаний о концепциях проектирования системы. Это включает в себя балансировку нагрузки, очереди сообщений, базы данных и т. д. К системе Tinder предъявляются четыре требования: хранение профилей, рекомендаций, отметка совпадений и общение с совпадениями. Хранение профилей тривиально, за исключением хранения изображений, где мы спорим о BLOB-объектах и ​​файловом хранилище. Распределенная файловая архитектура представляется наиболее оптимальной для хранения изображений. Обмен личными сообщениями или общение с совпадениями осуществляется по протоколу XMPP, который использует веб-сокеты для одноранговой связи между клиентом и сервером. Каждое соединение устанавливается по протоколу TCP, что гарантирует его сохранение. Микросервис сеанса может отправлять сообщения получателю, основываясь на сопоставлении соединения с пользователем. Наша система максимально разграничена. Мы стараемся сохранять информацию о принятии и отклонении на клиенте. При свайпе влево или вправо клиент может отметить действие и избежать повторного показа того же пользователя, возможно, используя фильтры Блума. На сервере есть механизм проверки, называемый микросервисом сопоставления, который отмечает совпадения и разрешает или запрещает общение между двумя пользователями. Последнее требование к рекомендациям — секционирование данных пользователей по городам. Это достигается с помощью NoSQL-баз данных, таких как Cassandra или Amazon Dynamo. Другой вариант — использование реляционных баз данных с горизонтальным секционированием. Эта концепция сейчас называется шардингом. Если у вас есть какие-либо сомнения, предложения или отзывы, буду рад их услышать ниже. Эта система ни в коем случае не является полной, но её хватит на часовое интервью. Отказ от ответственности: Видео не содержит и не предлагает внутреннюю реализацию Tinder. Система, которую мы разрабатываем, полностью воображаемая и не имеет никакой связи с реальным приложением. Уверен, инженеры Tinder справились лучше! 00:00 Предварительные требования 00:40 Выбор функций 05:50 Хранение изображений 12:30 Проектирование системы 18:22 Личные сообщения в чате 23:45 Алгоритм сопоставления 27:16 Рекомендательный механизм 34:40 Заключительные замечания CDN -    • System Design: Content Delivery Networks (...  

Последовательное хеширование -    • What is CONSISTENT HASHING and Where is it...   Ссылка на онлайн-оценку:
Плейлист «Проектирование системы» -    • System Design Playlist   Вы можете подписаться на меня в: LinkedIn:   / gaurav-sen-56b6a941   Twitter:   / gkcs_   #SystemDesign #SoftwareInterview #Tinder