💾 КЭШ — что важно знать системным аналитикам 💾
Кэш (cache) — быстрый временный слой хранения результатов вычислений или запросов API (и не только), чтобы при повторном обращении к серверу вернуть ответ не выполняя вычисления и логику запроса заново.
👉 Что хранит:
Уже вычисленные данные и/или их части:
JSON ответа, HTML-код, агрегаты, объекты
👉 Что кэшировать:
▫️Карточки сущностей, справочники - медленно меняющиеся сущности
▫️Списки с параметрами фильтров/пагинации
▫️Агрегаты/отчёты: дорогие запросы
▫️HTTP-404 на короткое время
👉 НЕ кэшировать:
▫️Ответы на изменяющие методы (POST/PUT/PATCH/DELETE)
▫️Секретные/чувствительные данные (no-store)
👉 Где хранится:
Для Frontend:
+ в памяти мобилок или десктопов
+ в памяти браузера
+ иногда в локальных БД
Для Backend:
+ CDN/прокси
+ Специализированные СУБД: Redis / Memcached
+ иногда в самой БД - готовые JSON, чтобы не вычислять
👉 Как искать нужные данные:
По ключу кэша - обычно это хеш нормализованного запроса/параметров
👉 Поведение алгоритмов при работе с кэшем:
✅ Cache Hit:
Если данные по ключу кэша найдены, то вернуть их.
Проверить время жизни кэша, прежде чем возвращать ответ
❌ Cache Miss:
Если кэш не найден или данные в кэше устаревшие, то приложение:
+ должно обратиться к источнику за данными (БД или вн. система)
+ формирует ответ (JSON или др)
+ пишет актуальные данные в кэш
🔖 Общий порядок работы на картинках к посту
👉 Политики вытеснения кэша (автоочистка)
▫️ LRU (Least Recently Used) — удаляем те ключи, к которым давно не обращались
▫️ LFU (Least Frequently Used) — удаляем ключи с наименьшим числом обращений
▫️ TTL (Time To Live) — запись жива фиксированное время, потом протухает
▫️ Size-based — выселение по суммарному объёму (байты), часто вместе с LRU/LFU
👉 Заголовки в REST API (Headers)
В запросах:
Cache-Control
If-None-Match
If-Modified-Since
If-Match
If-Unmodified-Since
Only-If-Cached
Pragma (устар.)
В ответах:
Cache-Control
ETag
Last-Modified
Vary
Expires
Age
Date
Cache-Status
Surrogate-Control
#hardGetAnalyst
Кэш (cache) — быстрый временный слой хранения результатов вычислений или запросов API (и не только), чтобы при повторном обращении к серверу вернуть ответ не выполняя вычисления и логику запроса заново.
👉 Что хранит:
Уже вычисленные данные и/или их части:
JSON ответа, HTML-код, агрегаты, объекты
👉 Что кэшировать:
▫️Карточки сущностей, справочники - медленно меняющиеся сущности
▫️Списки с параметрами фильтров/пагинации
▫️Агрегаты/отчёты: дорогие запросы
▫️HTTP-404 на короткое время
👉 НЕ кэшировать:
▫️Ответы на изменяющие методы (POST/PUT/PATCH/DELETE)
▫️Секретные/чувствительные данные (no-store)
👉 Где хранится:
Для Frontend:
+ в памяти мобилок или десктопов
+ в памяти браузера
+ иногда в локальных БД
Для Backend:
+ CDN/прокси
+ Специализированные СУБД: Redis / Memcached
+ иногда в самой БД - готовые JSON, чтобы не вычислять
👉 Как искать нужные данные:
По ключу кэша - обычно это хеш нормализованного запроса/параметров
👉 Поведение алгоритмов при работе с кэшем:
✅ Cache Hit:
Если данные по ключу кэша найдены, то вернуть их.
Проверить время жизни кэша, прежде чем возвращать ответ
❌ Cache Miss:
Если кэш не найден или данные в кэше устаревшие, то приложение:
+ должно обратиться к источнику за данными (БД или вн. система)
+ формирует ответ (JSON или др)
+ пишет актуальные данные в кэш
🔖 Общий порядок работы на картинках к посту
👉 Политики вытеснения кэша (автоочистка)
▫️ LRU (Least Recently Used) — удаляем те ключи, к которым давно не обращались
▫️ LFU (Least Frequently Used) — удаляем ключи с наименьшим числом обращений
▫️ TTL (Time To Live) — запись жива фиксированное время, потом протухает
▫️ Size-based — выселение по суммарному объёму (байты), часто вместе с LRU/LFU
👉 Заголовки в REST API (Headers)
В запросах:
Cache-Control
If-None-Match
If-Modified-Since
If-Match
If-Unmodified-Since
Only-If-Cached
Pragma (устар.)
В ответах:
Cache-Control
ETag
Last-Modified
Vary
Expires
Age
Date
Cache-Status
Surrogate-Control
#hardGetAnalyst
❤10
⚙️ Когда системный аналитик работает с REST API ⚙️
Когда затрагивают тему REST API, то полезно знать, что могут требовать от системного аналитика.
Предлагаем чек-лист в картинках, который можете применить, чтобы оценить текущий круг обязанностей и то, что может ожидать в будущих проектах 🙌
#hardGetAnalyst
Когда затрагивают тему REST API, то полезно знать, что могут требовать от системного аналитика.
Предлагаем чек-лист в картинках, который можете применить, чтобы оценить текущий круг обязанностей и то, что может ожидать в будущих проектах 🙌
#hardGetAnalyst
❤11
Короткие перерывы, которые помогут настроиться на работу👌
Друзья, мы составили короткий список полезных привычек, как можете помочь себе перезагрузиться в течение рабочего дня.
⏱️ 5 минут
• Медитация: найдите тихое место и сосредоточьтесь на дыхании. Можно использовать приложения для медитации с короткими треками.
• Суставная гимнастика: выполните простые упражнения для разминки суставов — покрутите головой, плечами, запястьями и лодыжками.
⏱️ 10 минут
• Прогулка на свежем воздухе: даже короткая прогулка поможет очистить голову и повысить уровень энергии.
• Чтение: уделите время чтению интересной книги, чтобы отвлечься от работы. В идеале выбирайте художественную литературу.
⏱️ 15 минут
• Дыхательные упражнения: сосредоточьтесь на дыхании, чтобы снизить уровень стресса и расслабиться.
• Ведение дневника: запишите мысли и чувства, чтобы прояснить ум и освободиться от напряжения. В качестве альтернативы можно вести дневник благодарности или запишите, за что можете гордиться собой.
⏱️ 20 минут
• Мини-тренировка: выполните несколько простых упражнений или растяжку, чтобы активизировать тело и улучшить кровообращение.
• Музыка: послушайте любимую музыку или подкаст, чтобы переключиться и поднять настроение.
#GAfrindlyreminder
Друзья, мы составили короткий список полезных привычек, как можете помочь себе перезагрузиться в течение рабочего дня.
⏱️ 5 минут
• Медитация: найдите тихое место и сосредоточьтесь на дыхании. Можно использовать приложения для медитации с короткими треками.
• Суставная гимнастика: выполните простые упражнения для разминки суставов — покрутите головой, плечами, запястьями и лодыжками.
⏱️ 10 минут
• Прогулка на свежем воздухе: даже короткая прогулка поможет очистить голову и повысить уровень энергии.
• Чтение: уделите время чтению интересной книги, чтобы отвлечься от работы. В идеале выбирайте художественную литературу.
⏱️ 15 минут
• Дыхательные упражнения: сосредоточьтесь на дыхании, чтобы снизить уровень стресса и расслабиться.
• Ведение дневника: запишите мысли и чувства, чтобы прояснить ум и освободиться от напряжения. В качестве альтернативы можно вести дневник благодарности или запишите, за что можете гордиться собой.
⏱️ 20 минут
• Мини-тренировка: выполните несколько простых упражнений или растяжку, чтобы активизировать тело и улучшить кровообращение.
• Музыка: послушайте любимую музыку или подкаст, чтобы переключиться и поднять настроение.
#GAfrindlyreminder
Telegram
👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
Помогаем аналитикам расти в карьере — чётко, по делу, через опыт и практику.
Разбираем реальные задачи, вопросы собеседований, даём инструменты и глубокое понимание тем:
Архитектура | Интеграции | API | Брокеры | AI и другие
Сообщество
👉@getanalysts
Разбираем реальные задачи, вопросы собеседований, даём инструменты и глубокое понимание тем:
Архитектура | Интеграции | API | Брокеры | AI и другие
Сообщество
👉@getanalysts
❤12🔥1
Headers в REST API: что это и зачем?
Headers – заголовки запроса и ответа в протоколе HTTP.
Это дополнительные системные параметры, которыми надо обмениваться. Обычно сквозные для всех методов в API, то есть применяются сразу для всех методов.
Помогают:
✔️ Определять, как обрабатывать запрос.
✔️ Передавать метаинформацию о данных (системную).
✔️ Настраивать взаимодействие между клиентом и сервером.
Проще всего разобраться с Headers, познакомившись с набором стандартных значений, которые можно нагло копировать в требования к вашим методам REST API 🙂
📌 Request Headers - заголовки для запросов в картинках к посту
📌 Response Headers - заголовки ответов
Полные подборки стандартных Headers:
🔗 Wikipedia
🔗 MDN
#hardGetAnalyst
Headers – заголовки запроса и ответа в протоколе HTTP.
Это дополнительные системные параметры, которыми надо обмениваться. Обычно сквозные для всех методов в API, то есть применяются сразу для всех методов.
Помогают:
✔️ Определять, как обрабатывать запрос.
✔️ Передавать метаинформацию о данных (системную).
✔️ Настраивать взаимодействие между клиентом и сервером.
Проще всего разобраться с Headers, познакомившись с набором стандартных значений, которые можно нагло копировать в требования к вашим методам REST API 🙂
📌 Request Headers - заголовки для запросов в картинках к посту
📌 Response Headers - заголовки ответов
Полные подборки стандартных Headers:
#hardGetAnalyst
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
Как собирать требования к ПО: проблемы и решения 📝
В подкасте разбираем, почему требования в первую очередь используют, чтобы поднять все явные и скрытые проблемы бизнеса, а только затем предлагают решения 👩💻
Обсудим:
✅ Что такое "верхний уровень", и как идут в глубину
✅ Полнота требований
✅ Про изобретение велосипедов
✅ Почему требования не читают
✅ Когда не нужно грузить заказчика
✅ Какие документы появляются в процессе сбора требований
Выпуск будет полезен системным и бизнес-аналитикам, а также всем, кто участвует в проектировании и запуске IT-продуктов.
Слушайте, делайте заметки и делитесь с коллегами!
#hardGetAnalyst
В подкасте разбираем, почему требования в первую очередь используют, чтобы поднять все явные и скрытые проблемы бизнеса, а только затем предлагают решения 👩💻
Обсудим:
✅ Что такое "верхний уровень", и как идут в глубину
✅ Полнота требований
✅ Про изобретение велосипедов
✅ Почему требования не читают
✅ Когда не нужно грузить заказчика
✅ Какие документы появляются в процессе сбора требований
Выпуск будет полезен системным и бизнес-аналитикам, а также всем, кто участвует в проектировании и запуске IT-продуктов.
Слушайте, делайте заметки и делитесь с коллегами!
#hardGetAnalyst
❤13🔥4👍1
👉 Функциональные требования (ФТ) — это про то, ЧТО делает система.
Для сервиса доставки еды это могут быть:
+ Пользователь может зарегистрировать личный кабинет в системе для отслеживания истории заказов, получения доступа к функциям электронного кошелька и программы лояльности.
+ Пользователь может искать блюда с учетом фильтров по названию, цене и наличию ингредиентов, а также сортировать результаты поиска.
+ Пользователь может добавить блюдо в корзину.
+ Пользователь может добавить удалить блюдо из корзины.
+ Пользователь может оформить заказ, когда наполнил корзину.
+ Пользователь может оплатить заказ банковской картой или с использованием электронного кошелька.
ФТ — фундамент любой системы.
👉 Нефункциональные требования (НФТ) — это про то, КАК система работает.
❗️ Любое НФТ должно быть проверяемым: либо в фукнциональных/авто-тестах, либо нагрузкой. Непроверяемые формулировки — просто "вода". Это не нужно.
Есть несколько основных видов НФТ, которые вы должны помнить всегда. Рассказываем про них с примерами:
1) Производительность - скорость работы системы.
👎 Система работает быстро.
✅ Время обработки запросов к системе не должно превышать 900 мс при 150 RPS и 300 одновременных пользователей.
2) Доступность и отказоустойчивость - время работы без сбоев.
👎 Обеспечить для системы высокую доступность.
✅ Публичный API должен быть доступен 99.9% в месяц.
✅ Регламентные окна ≤2 ч/мес.
✅ Допустимое время восстановления сервиса после сбоя (RTO) ≤ 15 мин.
✅ Допустимая потеря данных во времени при восстановлении (RPO) ≤ 1 мин для заказов и платежей.
3) Масштабируемость - способность расти в зависимости от нагрузки.
👎 Система должна легко и быстро масштабироваться при увеличении нагрузки от пользователей.
✅ В часы пик 12:00–15:00 и 18:00–21:00 по Мск входящий трафик возрастает в 3 раза относительно базовой нагрузки. Сервисы каталога товаров, заказов и платежей, должны автоматически масштабироваться, увеличивая количество активных инстансов (работающих экземпляров) в 4 раза без простоя.
4) Безопасность
👎 Обеспечить защиту данных.
✅ Система должна поддерживать аутентификацию по OAuth2/OIDC с обязательным PKCE для мобильных клиентов.
А ещё:
5) Целостность
6) Надежность
7) Удобство использования
😍 Эффективность
9) Переносимость
и другие виды НФТ.
Подробнее познакомиться с теорией и примерами по НФТ можно в подкасте:
Пример, когда не учтенные НФТ положили систему:
❗️ НФТ считаются одними из самых сложных для понимания аналитиков. Поэтому собрали для вас как примеры, так и реальные примеры их влияния на системы.
Обязательно повторите этот материал перед собеседованием на Junior/Middle позиции. Всегда будьте готовы объяснить разницу и привести примеры 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
getanalyst.ru
Нефункциональные требования: пример для медицинской системы
В этом эпизоде мы обсуждаем нефункциональные требования: не только в теории, но и на практике. Этот выпуск поможет системным и бизнес-аналитикам при подготовке к собеседованиям или перед стартом работы над ТЗ нового проекта.
👍10🔥5👏1