Решила обновить и расширить знания по дизайну систем. Начала с классики: читаю книгу с кабанчиком («Высоконагруженные приложения» Мартина Клепманна). Хочу поделиться тем, что усвоила после прочтения первой главы. Постараюсь объяснить на своих примерах.

Надежность

Существуют аппаратные сбои и программные ошибки.

Представим современное приложение с огромным количеством данных, которые нужно хранить. Например, «Кинопоиск». Там столько жестких дисков, что каждый день часть из них выходит из строя. Пользователи не простят сервису, если сломанное оборудование будет постоянно оставлять их без приятного вечера с любимым сериалом. Поэтому сейчас строят системы, которые адаптированы к аппаратным сбоям: незаметно для пользователя переключаются с нерабочего компонента на рабочий.

От программных ошибок нужно защищаться грамотным проектированием и всесторонним тестированием. Часто ошибки стреляют в тех местах, о которых никто не подумал, поэтому нужно настроить мониторинг и логирование, а также заранее подумать, как будем восстанавливаться, если ошибка приведёт к отказу.

Масштабируемость

Чтобы система не упала, когда мы выпустим ее из уютного мира тестовых стендов в суровый прод, нужно заранее описать предполагаемую нагрузку и подумать, как с такой нагрузкой обеспечить нужную производительность.

Нагрузку обычно описывают с помощью следующих параметров:
⭐️ Количество активных пользователей в день/месяц (DAU/MAU)
⭐️ Количество запросов в секунду (RPS)
⭐️ Отношение количества операций чтения к количеству операций записи в базу данных (по моему опыту это очень важная характеристика для проектирования системы).

Для описания производительности в веб-приложениях удобно использовать метрику времени ответа сервера (response time).

Если мы будем слать серверу один и тот же запрос много раз, время ответа будет каждый раз немного отличаться. Поэтому для оценки используют процентили (или перцентили). Например, время отклика 2 секунды для p99 означает, что 99 из 100 запросов выполняются менее, чем за 2 секунды, а 1 из 100 – за 2 секунды или дольше.

Чтобы справиться с нагрузкой используют вертикальное и горизонтальное масштабирование. Подробностей в первой главе особо нет, они будут дальше.
Если бы я объясняла это кому-то не из разработки, то объяснила бы так:
Когда цветку становится тесно в горшке, и мы пересаживаем в больший горшок – это вертикальное масштабирование.
Когда один кассир не успевает обработать большую очередь, открывают ещё одну или несколько касс – это горизонтальное масштабирование.

Удобство сопровождения

Здесь можно выделить удобство эксплуатации и возможности для развития. Для удобства эксплуатации нужен хороший мониторинг.
Для возможности развития приложения надо писать код так, чтобы:
🐱 в систему было легко добавлять новые фичи
🥹 новому разработчику было легко разобраться

Помню, когда я только начинала программировать, для меня самым важным было, чтобы код работал. Работает - ура! В процессе работы увидела, как много мы читаем кода и как часто меняется и дополняется ранее написанная функциональность. По мере приобретения этого опыта стала обращать большое внимание на то, чтобы мой код было легко прочитать, понять и расширить по мере необходимости.

Вот такие выводы и мысли по первой главе.

#сисдиз #кабанчик