☀️ Летняя неделя знаний от GetAnalyst: скидка 25% на все материалы для самостоятельного обучения ☀️

Если вы всерьёз решили расти в системном анализе — начните с практики 😉

📌 До 24 июля — скидка 25%
на все материалы для самостоятельного обучения:
✔️ разборы задач с проектов
✔️ структурные подходы к анализу требований
✔️ чек-листы, инструменты, шаблоны
✔️ подготовка к собеседованиям и разбор рабочих задач

🎁 Промокод: LETO2026

👉 Выбрать материалы со скидкой

Темы:
▫️ Интеграции
▫️ REST API
▫️ Архитектура
▫️ БД и SQL, ER-диаграммы
▫️ Резюме и собеседования
▫️ Анализ требований
▫️ AI


Это не теория ради теории — это практическая база, которая формирует мышление системного аналитика и помогает действовать увереннее в рабочих проектах.

Формат для тех, кто предпочитает учиться самостоятельно 🙌


Вопросы? Пишите @getanalyst или info@getanalyst.ru 📩


📱 Tg | 💙 ВК | 💬 Max

☀️ Скидка 25% на все мини-курсы: летняя неделя знаний до 24 июля ☀️

Внутри не несколько видео на 30 минут, а целые мини-курсы по 6–12 занятий, каждое из которых от 2 до 4 часов разбора задач.

Например:

▫️ БД и SQL: продвинутый уровень
Это три отдельных больших проекта с нуля: маркетплейс, страховая компания, медицинская система. В каждом — путь от анализа требований и ER-диаграммы до реальной БД, рабочих SQL и настройку ИИ-агентов.

▫️ Интеграции
практика в Postman по REST, GraphQL, gRPC, WebSocket и отдельный разбор типичных ошибок в интеграционных задачах на реальных проектах.

▫️ Архитектура
Разбор конкретных задач: как спроектировать взаимодействие между микросервисами и как выбрать между хореографией и оркестрацией в сложном асинхронном бизнес-процессе.

И другие темы.


☀️ До 24 июля — всё это на 25% дешевле

🎁 Промокод: LETO2026
👉 Смотреть каталог материалов


Формат для тех, кто предпочитает учиться самостоятельно 🤝


Вопросы? Мы на связи: @getanalyst или info@getanalyst.ru 💬


📱 Tg | 💙 ВК | 💬 Max

⚠️ «Настроить кэширование» — плохое требование. Вот какие 3 уровня вы упустили ⚠️


Браузер, CDN, сервер — кэш может одновременно использоваться на всех трёх уровнях.

А в требованиях чаще всего фигурирует только заголовок Cache-Control где-то на бэкенде, будто остальных двух уровней не существует.



👉 Разбираемся, что за что отвечает:


1️⃣ Клиентский кэш: браузер или мобильное приложение

Браузер может хранить HTTP-ответ локально и повторно использовать его, пока он считается актуальным.

Заголовок Cache-Control от сервера определяет, как долго ответ остаётся свежим, а заголовок ETag позволяет проверить его актуальность через условный запрос с If-None-Match. Если ресурс не изменился, сервер может вернуть 304 Not Modified без повторной передачи тела ответа.


2️⃣ CDN / edge-кэш

CDN (Content Delivery Network) — это сеть распределённых серверов, расположенных ближе к пользователям.

Она хранит копии ответов и может отдавать их без повторного обращения к основному серверу системы (origin-серверу). Один сохранённый ответ при этом может использоваться для множества пользователей.

Здесь особенно важно определить:
▫️ можно ли хранить ответ в общем кэше: public, private, no-store;
▫️ как долго он должен храниться: s-maxage, Edge TTL или другие настройки CDN;
▫️ какие параметры, заголовки и cookies входят в cache key;
▫️ нужен ли заголовок Vary;
▫️ как обрабатываются авторизованные и персонализированные ответы.

При неправильной конфигурации CDN может отдать пользователю вариант ответа, сформированный для другого контекста. Поэтому одной фразы «закэшировать ответ» недостаточно.

Отдельно нужна стратегия обновления CDN-кэша: дождаться окончания TTL, выполнить purge/invalidation или использовать версионирование URL.



3️⃣ Внутренний кэш приложения: Redis, in-memory и другие решения

Это временное хранилище данных внутри серверной части системы (Backend).

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

Это ускоряет работу приложения и снижает нагрузку на другие компоненты.

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

Поэтому в требованиях важно определить:

▫️ какие данные можно хранить в кэше;
▫️ как долго они могут там находиться;
▫️ после каких изменений кэш нужно обновить или очистить;
▫️ насколько допустимо показывать устаревшие данные;
▫️ что должна делать система, если кэш недоступен.



📌 Фраза «настроить кэширование» без указания уровня, цели и требований к актуальности данных слишком неоднозначна.

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


👉 Аналитику важно зафиксировать:

▫️ какие данные можно кэшировать и на каком уровне;
▫️ как долго они могут оставаться неактуальными;
▫️ при каких событиях кэш должен обновляться или очищаться;
▫️ что должна делать система, если кэш недоступен.

Иначе кэширование может не ускорить продукт, а стать источником устаревших данных, утечек и трудноуловимых ошибок.


А в ваших требованиях кэширование описано одной строчкой или отдельно для каждого уровня?


#RestApiGA #АрхитектураGA


📱 Tg | 💙 ВК | 💬 Max