Wiki

    Системный Дизайн

    Системный дизайн

    Подготовка

    1. Выяснить и согласовать скоупы (области действия) системы:
      • Юзкейсы
        • Кто будет использовать систему
        • Как будут использовать систему
      • Ограничения
        • Ограничения по траффику для скалирования
        • Ограничения скалирования (RPS, типы запросов, чтений в секунду, записей в секунду
    2. Высокоуровневый дизайн (Абстрактный)
      • Нарисовать самые важные компоненты и связи между ними
        • Application service layer (serves the requests)
        • Список необходимых сервисов
        • Уровень хранения данных
        • Load balancer, сервисы для кэширования, master/slave базы данных
    3. Компонентный дизайн
      • Компонент + его API
      • Объектно-ориентированный дизайн:
        • Смаппить фичи в модули: один сценарий для одного модуля
        • Связи между модулями
      • Схема базы данных
    4. Понять узкие места системы
      • Может системе нужен балансировщик и много машин за ним для того чтобы выдержать траффик
      • Или данных слишком много и их надо разбивать по нескольким БД
      • Или база данных слишком медленная и нужно кэширование
      • Какие подводные камни у каждого из решений для узких мест?
    5. Скалирование высокоуровнего дизайна
      • Вертикальное скалирование: +CPU, +RAM
      • Горизонтальное скалирование: увеличить пул машин
      • Кэширование:
        • На уровне приложения
        • На уровне БД. Чаще всего идет вместе с БД, возможно нужно доконфигурировать. Плюс, желательно следить, чтобы индексы влезали в RAM
        • In-memory кэш. Redis или Memcached
    6. Балансировщик нагрузки
    7. Репликация БД
    8. Партицирование БД.

    Ключевые топики для дизайна системы

    1. Параллелизм и конкурентность.
      • Do you understand threads, deadlock, and starvation? Do you know how to parallelize algorithms? Do you understand consistency and coherence?
    2. Сеть.
      Do you roughly understand IPC and TCP/IP? Do you know the difference between throughput and latency, and when each is the relevant factor?
    3. Абстракции
      You should understand the systems you’re building upon. Do you know roughly how an OS, file system, and database work? Do you know about the various levels of caching in a modern OS?
    4. Real-World Performance
      You should be familiar with the speed of everything your computer can do, including the relative performance of RAM, disk, SSD and your network.
    5. Availability & Reliability
      Are you thinking about how things can fail, especially in a distributed environment? Do know how to design a system to cope with network failures? Do you understand durability?

    Соображения по дизайну веб-приложений

    • Security (CORS)
    • CDN
    • Полнотекстовый поиск. Using Sphinx/Lucene/Solr - which achieve fast search responses because, instead of searching the text directly, it searches an index instead.
    • Server Side rendering
    • Asynchronous loading of assets (Lazy load items)
    • Internationalization

    Пример: URL shortener

    Задача: Спроектируй сервис коротких ссылок, как bit.ly

    Юзкейсы

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

    • Создание коротких ссылок
    • Редирект по короткой ссылке
    • Аналитика
    • Выбор "красивого" урла юзером

    Доп фичи:

    • Автоматическое устаревание ссылок
    • Ручное устаревание ссылок
    • UI

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

    • Высокая доступность
    • Минимальная задержка редиректов
    • Укороченные ссылки не должны быть предсказуемыми

     Ограничения

    • Допустим, что нужен топ 10 сервис по укорочиванию ссылок.

      Возьмем одну из крупнейших соцсетей - Твиттер. У него 15 новых миллиардов твитов в месяц. Допустим, каждый из 10 твитов содержит укороченную ссылку.

      Тогда крупнейших сервис - 1.5 млрд ссылок в месяц.
      Тогда сайты за топ 3 - примерно 300 млн ссылок в месяц.
      Тогда пусть сайт топ10 - 100 млн ссылок в месяц

    • Пусть 10% - создание ссылок, 90% - переход по ссылкам

    • ~ 400 rps -> 40 rps на создание, 360 rps на переход

    • Ограничение по данным. Предположим на 5 лет:
      5 лет * 12 месяцев * 100 млн ссылок = 6 млрд ссылок
      ~500 байт на целевой URL -> ~3 тб на все урлы
      Хэш где-то 6 символов -> ~6 байт на хэш -> 36 гб на все хэши.

    • Запись данных в секунду: 40 rps * (500 + 6) = 20k байт/c

    • Чтение данных в секунду: 360 rps * (500 + 6) = 180k байт/c

    Верхнеуровневый дизайн

    Прикладной уровень

    • Сервис по укорачиванию ссылок
    hashed_url = to_base62(md5(original_url + random_salt))[:6]

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

    Уровень данных

    БД должна вести себя как большая хэш таблица. Так как не будет (или почти не будет) связей в моделях, то скорее всего не нужна SQL БД.

    Компонентный дизайн

    API

    АПИ доступно по ключу - api_dev_key. Ставим ограничение по кол-во запросов с ключом, запрещаем запросы без него.

    Создание ссылки

    createURL(api_dev_key, original_url, custom_alias=None, user_name=None, expire_date=None)

    Parameters:
    api_dev_key (string): The API developer key of a registered account. This will be used to, among other things, throttle users based on their allocated quota.
    original_url (string): Original URL to be shortened.
    custom_alias (string): Optional custom key for the URL.
    user_name (string): Optional user name to be used in the encoding.
    expire_date (string): Optional expiration date for the shortened URL.

    Удаление ссылки

    deleteURL(api_dev_key, url_key)

    Схема БД

    attachments/Pasted image 20230929224145.png

    Узкие места

    • Траффик не слишком большой - не проблема
    • Кол-во данных - более интересно