System Design: распределенный чат

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

System Design: распределенный чат

Этап 3. API Design. ● На этом этапе спроектирован API, который предоставляет система. ● Был определен набор процедур, протоколов и эндпоинтов, необходимых для взаимодействия с системой и между ее компонентами. ● Необходимо предоставить ручки для: - Аутентификации. - Выхода из системы. - Отправки сообщений. - Получения сообщений. ● Такой набор ручек позволит разработчикам со знанием сигнатуры процедур и наличием их полного описания с лучшим пониманием подходить к их реализации в будущем. Этап 4. Architecture Diagramming. ● На финальном этапе визуально задокументированы в виде диаграмм флоу аутентификации, отправки сообщений в приватный/публичный чат, а также общая архитектура решения, представляющая из себя кооперативную диаграмму в нотации C4 Model и содержащая все компоненты системы и их взаимодействия между собой.

System Design: распределенный чат

Этап 1. Capacity Planning. ● Важно было понять масштаб проектируемой системы. Для этого была выполнена оценка вычислительной нагрузки и нагрузки по количеству обрабатываемых данных от внешних пользователей. Кроме того, нужно было оценить, как эта нагрузка будет влиять на состояние системы. Этап 2. Data Flow Evaluation. ● На этом этапе была проведена оценка потоков данных, выбрана модель данных и то, как они пишутся и читаются. ● Распределенный чат - write-intensive приложение. Это значит, что в системе выполняется больше операций записи в хранилища данных, нежели чтения. ● Этот факт повлиял на выбор модели индексации данных. Вместо классического B-tree было решено использовать индексацию данных на основе LSTM-tree, который позволяет быстро записывать, но при этом значительно медленнее считывать данные из хранилища. ● Реализуется такая модель данных за счет наличия множества структур данных, постепенно сливающихся из самого верхнего уровня (оперативная память) к самому нижнему (жесткий диск сервера). Как только новая запись приходит в базу данных, она быстро записывается в оперативную памяти и дальше спускается все ниже и ниже по дереву, из-за чего возникают издержки при чтении данных по данному индексу. ● Модель данных повлияла и на выбор базы данных. В данном случае оптимально использовать такие решения, как Apache Cassandra или ScyllaDB - чтобы на основе представленного индекса распределять данные по разным серверам базы данных в разных регионах. ● Кроме того, выбор базы данных привел к денормализации данных, при этом оптимизировав работу с хранилищем. Отмечу, что факт потери свойств нормализованной модели данных на нас не влияет.