System design framework (part 2)

Основные форматы для коммуникации внутри системы: JSON, CSV, XML (SOAP - пахнет старостью)
Binary: Protobuff, Thrift, Avro (Schema-based, Hadoop and Kafka)

Ссылка на доклад Стаса по нетворку https://drive.google.com/file/d/1ZIyhKZbdZ3n65bfXrlbwi5JoMSjAidsM/view?usp=sharing Как правило внутрення коммуникация между сервисами построена на gRPC/Protobuff

Пример: построить плаформу над IOT девайсами - ACK=0 (не дожидаться экноледжмента, уменьшить нагрузку)

Если нам нужно 100 % сохранять результат мы используем:

ACK=Quorum
ACK=ALL

Вывод:
Нужно думать о месседж экноледжменте в зависимости от задачи

Как правила на системс дизайне речь идет о распределенном кеше Redis/Memcache.

Подходы в кешировании

На уровне времени
- Expiration date Со временем значение сохраненных данных может быть невалидно => мы используем EXPIRE Пример:
  - Рейт Лимитер
- Refresh on Request
На уровне размера
- LRU (least-recently-used) Хороший пример использования:
  - Redis
  - TickTock (hot topics)
- LFU (least frequently used cache) Сверху будут записи с самой большой фриквенси (наименее повторяющиеся элементы - кандидаты на вылет) Примеры задач с литкода
https://leetcode.com/problems/lfu-cache/
https://leetcode.com/problems/lru-cache/

Кеш паттрены

Cache-Aside Сервис смотрит в кеш если нет то смотрит в базе и сетит в кеш
Read and Write Through С начала пишем/читаем в/из кеш и потом результат уходит в базу (Можно потерять данные при падении кеша) Трейдофы из книг #todo
Write Behind Добавление в очередь и очередь запишет значение в ДБ позже

Лекция: https://drive.google.com/file/d/1xDtRKtkT34CvWzZA4Wsi1BBMe_b7hX1K/view?usp=sharing

RabbitMQ, Kafka - основные месседж брокеры на системс дизайне (иногда SQS)

Message consumption patterns:

Push - брокер отправляет сообщение (RabbitMQ, ActiveMQ) Pull - брокер позволяет вытягивать сообщения (Kafka, SQS)

Сервис дискавери

Host discovery - DNS Service Discovery - (Service Registry, Spring Cloud Eureka, Kubernetes) Peer Discovery: - Gossip protocol (example: Cassandra, DynamoDB, Riak, S3) - ZooKeeper

CDN Солюшен для хостинга файлов

Распределен географически
Основная задача быть как можно ближе к пользователю

Примеры CloudFlare, Akamai, CloudFront

^ отвечаем на вопрос как сделать систему более надежней

Timeouts
Handling Failed Requests
- Failover -> switch to another node
- Fallback -> switch to another direction Пример: Обслуживание 40к стастистики с мобильных девайсов для построения аналитики - все данные должны быть сохранены в таком случае мы используем fallback сценарий
Retries
- Небезопасный подход - отправка реквестов которые мутируют состояние (добавить в баланс 100 долларов) Так лучше не делать лучшая стратегия это отменить такой реквест
- Идемпотентные реквесты - вне зависимости от кол во повторений реквестов окончательный результат будет тот же Вывод:
- Не все реквесты можено ретраить
- Read request можно ретраить безконечно Как ретраиться?
- Кол-во ретарев
- Ехпоненшиал ретрай (Самый безопасный механизм)
- ретрай ограничения

Вопрос к интервьюеру: Можно ли отключить ретрай механизм в случае Peek Hours?

99 percentile

Пример применения батчинга: 1000 однородных запросов - 1000 json - подход отправить все запросы одним скопом (increase throughput)

Компрессия:

Snappy
ZSTD

Estimations: RPS = number of cores * (1/Task duration) CPU bounded RPS = (Total RAM / Task memory usage) * (1/Task duration) Memory bounded (как правило нижняя формула опускается)