Нефункциональные требования

  1. DAU = 1 million
  2. Объем данных - 1 million tickers
    1. 12 байт на котировку
    2. У каждого клиента максимум 1000 tickers
  3. Необходимо реализовать ultra-low latency систему. То есть сократить момент, когда биржа сделала event в нашу сторону и мы показали его клиенту
    1. Под ultra-low-latency мы закладываем SLO отдачи информации от момента публикации у Брокера до момента получения инфы клиентом. У нас это будет до 200 мс. Почему такая цифра? → Больше уже глаз человека начинает замечать различия.
  4. Прикинем, что для каждого ticker будет 10 обновлений в секунду
  5. Также наша система будет вычитывать и хранить все tickers (1 million), чтобы минимизировать задержку получения новых тикеров, а также упростить логику
  6. Про геораспределенность: так как наша система получает данные от Биржы, то нам не нужно синковать данные между нашими кластерами.

Также необходимо допом сказать про особенности системы:

  1. Потенциально кластера должны находиться в стране, где мы работаем. Так как иначе есть риск, что нам не разрешат работать в ряде стран.
  2. В реальности нужно продумать, а как мы будем обеспечивать синхронность/одинаковость данных между разными странами. Условно, в Аргентине сервера упали и клиенты там не получат данные, а в Таиланде клиенты будут получать эту инфу.
  3. В рамках Неделя 6 будет сказано про Надежность и как ее можно посчитать. На реальном собесе стоит сказать, что нам в реальной системе нужно учитывать Uptime и поэтому понадобятся доп расчеты.

Важно

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

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