🔥 Подвохи в REST API: разбор типовых ошибок🔥🙃
На этой неделе я публиковала задачи по REST API и просила вас проголосовать за правильные ответы.
📌 Если вы их пропустили, то сначала решите задачи здесь, а затем вернитесь к этому посту за разбором.
Типичные ошибки:
👉1) Список вакансий
Разбор тут
👉2) Просмотр вакансии
• Передавали jobId вакансии в query-параметре, хотя корректнее в path - это самая распространенная ошибка ❗️ Query-параметры для фильтров и сортировок списков.
• Добавляли details в URL — это лишнее, если уже есть {jobId} в path-параметрах
• Немногие попались на подвох с доменом api.com (3%)
👉3) Создание вакансии рекрутером
• ❗️ В URL добавляли create при POST — лишнее (“масло-масляное”). Это самая распространенная ошибка
• В варианте A, где указано recruiter (название каталога api?), желательно перенести название каталога api до версии, хотя и так допустимо
• ❗️Передавали jobId при создании вакансии — обычно он генерируется на сервере после её создания, поэтому в запросе его быть не должно (вариант I, распространенная ошибка).
• Потерян указатель на каталог API, но это не критично.
👉4) Отклик кандидата на вакансию
• ❗️В URL добавляли create при POST — лишнее (“масло-масляное”).
• PATCH для частичного редактирования данных, но не для создания отклика (C = 10%).
• В сущностях не рекомендуется указывать глаголы, если это не метод редактирования PATCH (D, H).
• Подставляли в URL id кандидата, хотя его лучше было бы отправить в тело, так как в предложенных вариантах до {candidateId} нет /candidate, чтобы мы в целом имели право его прописывать (F, G). Популярная ошибка ❗️
👉5) Изменение статуса отклика
• "Масло-масляное" с глаголом update/change и методами на изменение PUT/PATCH (C, H, J)
• Путаница с пониманием PUT и PATCH. PUT - полное редактирование, PATCH - частичное редактирование ресурса, когда надо перезаписать одно поле у сущности в БД, а не все.
👉 Подробно все ошибки указала на картинках к посту.
Вопросы?
Пишите в комментариях.
Изучайте разбор и запоминайте ошибки.
Для собеседований такая практика 100% пригодится 🤝
#RestApiGA
На этой неделе я публиковала задачи по REST API и просила вас проголосовать за правильные ответы.
📌 Если вы их пропустили, то сначала решите задачи здесь, а затем вернитесь к этому посту за разбором.
Типичные ошибки:
👉1) Список вакансий
Разбор тут
👉2) Просмотр вакансии
• Передавали jobId вакансии в query-параметре, хотя корректнее в path - это самая распространенная ошибка ❗️ Query-параметры для фильтров и сортировок списков.
• Добавляли details в URL — это лишнее, если уже есть {jobId} в path-параметрах
• Немногие попались на подвох с доменом api.com (3%)
👉3) Создание вакансии рекрутером
• ❗️ В URL добавляли create при POST — лишнее (“масло-масляное”). Это самая распространенная ошибка
• В варианте A, где указано recruiter (название каталога api?), желательно перенести название каталога api до версии, хотя и так допустимо
• ❗️Передавали jobId при создании вакансии — обычно он генерируется на сервере после её создания, поэтому в запросе его быть не должно (вариант I, распространенная ошибка).
• Потерян указатель на каталог API, но это не критично.
👉4) Отклик кандидата на вакансию
• ❗️В URL добавляли create при POST — лишнее (“масло-масляное”).
• PATCH для частичного редактирования данных, но не для создания отклика (C = 10%).
• В сущностях не рекомендуется указывать глаголы, если это не метод редактирования PATCH (D, H).
• Подставляли в URL id кандидата, хотя его лучше было бы отправить в тело, так как в предложенных вариантах до {candidateId} нет /candidate, чтобы мы в целом имели право его прописывать (F, G). Популярная ошибка ❗️
👉5) Изменение статуса отклика
• "Масло-масляное" с глаголом update/change и методами на изменение PUT/PATCH (C, H, J)
• Путаница с пониманием PUT и PATCH. PUT - полное редактирование, PATCH - частичное редактирование ресурса, когда надо перезаписать одно поле у сущности в БД, а не все.
👉 Подробно все ошибки указала на картинках к посту.
Вопросы?
Пишите в комментариях.
Изучайте разбор и запоминайте ошибки.
Для собеседований такая практика 100% пригодится 🤝
#RestApiGA
❤14🔥4
💜 [Доступ открыт] Postman + Insomnia + AI 🧡
Открыли доступ к бесплатному практическому занятию для СА и БА, где мы разбираем 3 ключевых инструмента для работы с REST API в 2026:
🤖 Postman, Insomnia и AI:
🔥 погружение в REST API на реальных примерах
🗓 Только до 17 февраля [вт]
🕘 Время на обучение: ~3.5 часа
🔗 Зарегистрироваться
(если уже регистрировались, то ссылка с доступом пришла на почту сегодня утром)
В результате этого обучения:
✅ Получите опыт работы с Postman и Insomnia.
✅ Сделаете коллекции запросов к реальному API для личного портфолио.
✅ Научитесь использовать AI-инструменты (GeminiAI + ChatGPT) на продвинутом уровне.
✅ Получите примеры постановок задач на REST API-методы.
Пусть это будет ваш быстрый апгрейд по REST API на этой неделе! 🚀💜🧡
—————————————————
👩🎓 Открытый урок проводится в качестве вводного занятия к практической программе Дизайн REST API.
Открыли доступ к бесплатному практическому занятию для СА и БА, где мы разбираем 3 ключевых инструмента для работы с REST API в 2026:
🔥 погружение в REST API на реальных примерах
🕘 Время на обучение: ~3.5 часа
(если уже регистрировались, то ссылка с доступом пришла на почту сегодня утром)
В результате этого обучения:
✅ Получите опыт работы с Postman и Insomnia.
✅ Сделаете коллекции запросов к реальному API для личного портфолио.
✅ Научитесь использовать AI-инструменты (GeminiAI + ChatGPT) на продвинутом уровне.
✅ Получите примеры постановок задач на REST API-методы.
Пусть это будет ваш быстрый апгрейд по REST API на этой неделе! 🚀💜🧡
—————————————————
👩🎓 Открытый урок проводится в качестве вводного занятия к практической программе Дизайн REST API.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥10🔥2❤1👍1
Вы только что сделали мой вечер субботы. Откройте скрины — там прям очень сильные слова 🙈❤️🔥💖
Сегодня пришло сообщение с первой картинки — и я поймала себя на мысли: миссия выполнима.
P.S. А ещё истории:
🩵 Дизайн REST API
🧡 Интеграции систем
Спасибо вам за доверие.
Спасибо, что пишете и делитесь.
Это правда очень-очень ценно ❤️🔥
#студентыGetAnalyst
Сегодня пришло сообщение с первой картинки — и я поймала себя на мысли: миссия выполнима.
P.S. А ещё истории:
🩵 Дизайн REST API
🧡 Интеграции систем
Спасибо вам за доверие.
Спасибо, что пишете и делитесь.
Это правда очень-очень ценно ❤️🔥
#студентыGetAnalyst
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤19❤🔥1🔥1
💜🧠 Доступ к практике Postman + Insomnia + AI для REST API завершается завтра 🧠 🧡
Всем зарегистрированным участникам письмо с доступом дублировали на почту сегодня утром.
Если не нашли письмо или ещё не регистрировались:
🔗 Получить доступ
🗓 Только до 17 февраля (вт), 23:59 Мск.
Успевайте посмотреть! 👇
👉 Это та практика, после которой нам пишут:
Roxel
Julia
Юлия
И если у вас:
🔹 на собесах ответы по REST “плывут”
🔹 в работе API есть, но уверенности нет
🔹 Про Postman и Insomnia - только слышали
🔹 Не используете AI для работы
Тогда эта практика точно поможет закрыть много пробелов и реально прокачает ваши знания! 🚀
Планируйте время и забирайте ценный опыт + наработки в своё портфолио!
————————————
👩🎓 Эта практика - вводное занятие к практической программе Дизайн REST API.
————————————
Вопросы? Пишите @getanalyst или info@getanalyst.ru
Всем зарегистрированным участникам письмо с доступом дублировали на почту сегодня утром.
Если не нашли письмо или ещё не регистрировались:
Успевайте посмотреть! 👇
👉 Это та практика, после которой нам пишут:
Roxel
Это очень практичный и очень полезный вебинар. Это практикум! Все материалы систематизированы, урок прошел на одном дыхании. Это магия! Спасибо борльшое, Екатерина! Вы самый крутой профессионал, который преподает в домене Системного анализа на русском языке! Вы - СУПЕР!
Julia
Большое спасибо за занятие! Очень много полезной информации и практических примеров. На мой взгляд Катя сейчас один из лучших лекторов по системному анализу.
Юлия
очень полезно, особенно про AI-ассистента
И если у вас:
🔹 на собесах ответы по REST “плывут”
🔹 в работе API есть, но уверенности нет
🔹 Про Postman и Insomnia - только слышали
🔹 Не используете AI для работы
Тогда эта практика точно поможет закрыть много пробелов и реально прокачает ваши знания! 🚀
Планируйте время и забирайте ценный опыт + наработки в своё портфолио!
————————————
👩🎓 Эта практика - вводное занятие к практической программе Дизайн REST API.
————————————
Вопросы? Пишите @getanalyst или info@getanalyst.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4❤🔥3💯1
◻️ Общие архитектурные понятия
1. Архитектура системы
2. Компонент
3. Модуль
4. Подсистема
5. Сервис
6. Backend
7. Frontend
8. Web-приложение
9. Сайт
10. Desktop-приложение
11. Мобильное приложение
12. Виджет
🧱 Архитектурные стили и подходы
13. Монолитная архитектура
14. Модульный монолит
15. Сервис-ориентированная архитектура (SOA)
16. Микросервисы (MSA)
17. Событийно-ориентированная архитектура (EDA)
18. Слоистая архитектура
19. API Gateway
20. Хореография
21. Оркестрация
22. Service Registry and Discovery
23. Backend for Frontend (BFF)
24. Database-per-Service (БД на сервис)
25. CQRS (Command Query Responsibility Segregation)
26. Domain-Driven Design (DDD)
27. Event Storming
28. Чистая архитектура
🔗 Интеграция и взаимодействие компонентов
29. API (Application Programming Interface)
30. REST API
31. GraphQL
32. gRPC
33. SOAP
34. WebSocket
35. Синхронное взаимодействие
36. Асинхронное взаимодействие
37. Webhooks
38. Polling
39. Long Polling
40. Message Broker (Брокер сообщений)
41. Kafka
42. RabbitMQ
43. ESB (Enterprise Service Bus)
💾 Хранение данных
44. База данных (БД)
45. СУБД
46. Реляционные БД (PostgreSQL, SQLite, MySQL, Oracle и др.)
47. NoSQL БД (MongoDB, Redis и др.)
48. Файловое хранилище
49. Шардирование
50. Репликация
51. Кэширование
🔐 Безопасность
52. Authentication (Аутентификация)
53. Authorization (Авторизация)
54. SSO (Single Sign-On)
55. OAuth 2.0
56. JWT
57. Token
58. Bearer Token
59. Basic Authentication
60. Keycloak
61. TLS
62. HTTPS
63. WWS
64. Аудит
🖼 Нефункциональные требования (НФТ)
65. Масштабируемость
66. Доступность
67. Отказоустойчивость
68. Производительность
69. Сопровождаемость
70. Безопасность
⚙️ DevOps и инфраструктура
71. CI/CD (Continuous Integration / Continuous Delivery)
72. Балансировщик нагрузки (Load Balancer)
73. Docker
74. Kubernetes
75. Service Mesh
76. Мониторинг (Prometheus, Grafana, Zabbix и др.)
77. Логирование (ELK с Kibana, Loki + Grafana и др.)
78. Дашборды
79. Tracing
80. Health Check
📐 Проектирование и документация
81. UML Sequence Diagram
82. UML Activity Diagram
83. C4 Model (Context, Container, Component, Code)
84. Archimate
85. ERD (Entity-Relationship Diagram)
86. Нефункциональные требования (НФТ)
87. Архитектурные решения
P.S. Есть что добавить? Пишите в комментарии!
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥45❤17👍5❤🔥2👎2
GetAnalyst_7_шаблонов_архитектуры.pdf
1.5 MB
📌 7 шаблонов архитектуры, которые важно понимать СА 📌
В простых проектах аналитикам не надо разбираться в архитектуре.
Но в больших продуктовых компаниях, как банки, маркетплейсы, страховые и т.п., где преобладают сервисная (SOA) и микросервисная (MSA) архитектуры, аналитикам важно разбираться в этом вопросе.
👉 Обычно спрашивают знание этих шаблонов:
1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-Ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)
Понимание видов архитектуры нужно, чтобы грамотно проектировать новые функции и правильно интегрировать их в существующую инфраструктуру.
📚 В мини-книге к посту вы найдёте:
+ описание каждого подхода,
+ связи между ними,
+ картинки,
+ примеры.
Сохраняйте, изучайте и пользуйтесь!
P.S. А если интересна архитектура для кода, то рекомендую подкаст про Чистую архитектуру
#АрхитектураGA
В простых проектах аналитикам не надо разбираться в архитектуре.
Но в больших продуктовых компаниях, как банки, маркетплейсы, страховые и т.п., где преобладают сервисная (SOA) и микросервисная (MSA) архитектуры, аналитикам важно разбираться в этом вопросе.
👉 Обычно спрашивают знание этих шаблонов:
1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-Ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)
Понимание видов архитектуры нужно, чтобы грамотно проектировать новые функции и правильно интегрировать их в существующую инфраструктуру.
📚 В мини-книге к посту вы найдёте:
+ описание каждого подхода,
+ связи между ними,
+ картинки,
+ примеры.
Сохраняйте, изучайте и пользуйтесь!
P.S. А если интересна архитектура для кода, то рекомендую подкаст про Чистую архитектуру
#АрхитектураGA
❤30👍4🍾3❤🔥1😱1🤩1
🔴 Архитектура рекламной платформы: микросервисы, EDA, Kafka 🟢
В этом месяце будем проектировать архитектуру рекламной платформы #AdFlowGA 👩💻🧑💻
👉 Предыстория:
Пару лет назад в России стала обязательной маркировка интернет-рекламы: перед запуском объявление должно получить уникальный идентификатор ERID через оператора рекламных данных (ОРД), а сведения попадают в Единый реестр интернет-рекламы (ЕРИР), который ведёт Роскомнадзор.
Из-за этого теперь недостаточно просто завести объявление в кабинете Яндекс / ВК / Telegram — нужно пройти цепочку: маркировка → публикация → учёт → отчётность.
👉 Как это должно работать по шагам:
1. Создание креатива в платформе
текст/баннер/видео + целевая площадка, ссылка, параметры кампании.
2. Автопроверки
формат, запрещённые слова/URL, обязательные поля и др.
3. Ручная модерация
очередь, статусы, комментарии, возврат на доработку.
4. Регистрация рекламы в ОРД
получение ERID.
5. Публикация объявления на выбранной площадке
интеграция с рекламными API.
6. Активация рекламы + запуск биллинга
резерв/списание бюджета, старт учёта показов/кликов/расходов.
7. Сбор статистики с площадок + хранение истории изменений для отчётности и аудита.
8. Передача обязательных данных по статистике в ОРД/ЕРИР
👉 С чем именно мы будем работать на проекте:
1️⃣ Проектирование микросервисов
Как разделить на независимые части рекламную платформу.
2️⃣ API Gateway
Единая точка входа для мобильных и веб-клиентов.
3️⃣ Интеграции
С системами маркировками и платформами для размещения рекламы.
4️⃣ Оркестрация vs Хореография
Подходы к управлению процессами.
5️⃣ Брокеры RabbitMQ и Kafka
Когда и какой брокер выбрать, их устройство и ключевые принципы работы.
6️⃣ Схема архитектуры в С4
Оформим схемы в международных стандартах.
🧩 Будем делать схемы, продумывать потоки данных и разбирать, почему одно архитектурное решение здесь работает лучше другого.
👉 Хотите участвовать?
Подписывайтесь на @getanalysts и следите за хэштегами #AdFlowGA и #АрхитектураGA в ближайший месяц 🏷
Добро пожаловать в команду! 🤝
———-
P.S. Вчера был пост про 84 термина по архитектуре. Если на чём-то ещё важно сделать фокус и показать примеры, пишите в комментариях 👇
В этом месяце будем проектировать архитектуру рекламной платформы #AdFlowGA 👩💻🧑💻
👉 Предыстория:
Пару лет назад в России стала обязательной маркировка интернет-рекламы: перед запуском объявление должно получить уникальный идентификатор ERID через оператора рекламных данных (ОРД), а сведения попадают в Единый реестр интернет-рекламы (ЕРИР), который ведёт Роскомнадзор.
Из-за этого теперь недостаточно просто завести объявление в кабинете Яндекс / ВК / Telegram — нужно пройти цепочку: маркировка → публикация → учёт → отчётность.
👉 Как это должно работать по шагам:
1. Создание креатива в платформе
текст/баннер/видео + целевая площадка, ссылка, параметры кампании.
2. Автопроверки
формат, запрещённые слова/URL, обязательные поля и др.
3. Ручная модерация
очередь, статусы, комментарии, возврат на доработку.
4. Регистрация рекламы в ОРД
получение ERID.
5. Публикация объявления на выбранной площадке
интеграция с рекламными API.
6. Активация рекламы + запуск биллинга
резерв/списание бюджета, старт учёта показов/кликов/расходов.
7. Сбор статистики с площадок + хранение истории изменений для отчётности и аудита.
8. Передача обязательных данных по статистике в ОРД/ЕРИР
👉 С чем именно мы будем работать на проекте:
1️⃣ Проектирование микросервисов
Как разделить на независимые части рекламную платформу.
2️⃣ API Gateway
Единая точка входа для мобильных и веб-клиентов.
3️⃣ Интеграции
С системами маркировками и платформами для размещения рекламы.
4️⃣ Оркестрация vs Хореография
Подходы к управлению процессами.
5️⃣ Брокеры RabbitMQ и Kafka
Когда и какой брокер выбрать, их устройство и ключевые принципы работы.
6️⃣ Схема архитектуры в С4
Оформим схемы в международных стандартах.
🧩 Будем делать схемы, продумывать потоки данных и разбирать, почему одно архитектурное решение здесь работает лучше другого.
👉 Хотите участвовать?
Подписывайтесь на @getanalysts и следите за хэштегами #AdFlowGA и #АрхитектураGA в ближайший месяц 🏷
Добро пожаловать в команду! 🤝
———-
P.S. Вчера был пост про 84 термина по архитектуре. Если на чём-то ещё важно сделать фокус и показать примеры, пишите в комментариях 👇
🔥42❤14❤🔥6
🗺️ 5 подходов к определению границ микросервисов 🗺️
Хорошая декомпозиция системы на микросервисы — это когда по каждому сервису понятно:
✔️ чем владеет (данные),
✔️ какие функции выполняет,
✔️ что он гарантирует (SLA),
✔️ и как реагирует на сбои.
Разберём 5 ключевых подходов к декомпозиции системы на микросервисы на примере проекта по управлению рекламой #AdFlowGA👇
———
1️⃣ По группам функций
Каждый микросервис объединяет логически связанные функции.
🔹 Сервис объявлений
Создание и редактирование креативов, версии, черновики, статусы.
🔹 ERID-сервис
Интеграция с ОРД, регистрация рекламы, хранение ERID, ретраи при ошибках.
🔹 Управление публикациями
Интеграции с рекламными API (VK, Telegram и др.), получение platformAdId.
🔹 Сервис биллинга
Резерв бюджета, списания, учёт показов, финансовая отчётность.
Подход понятный.
Но может игнорировать реальные доменные границы и различия в SLA.
———
2️⃣ По доменам (DDD — Bounded Context)
Выделяем ограниченные контексты с собственными правилами и моделями данных.
🔹 Домен “Управление объявлениями”
Креативы, статусы, версии, бизнес-правила переходов состояний.
🔹 Домен “Маркировка”
ERID, интеграция с ОРД, требования к отчётности, юридические ограничения.
🔹 Домен “Публикация”
Работа с API площадок, синхронизация статусов, дедупликация запросов.
🔹 Домен “Финансы”
Резервы, списания, корректировки, возвраты.
Важно:
разные домены = разные SLA и разные требования к отказоустойчивости.
———
3️⃣ По данным (Data Ownership)
Каждый сервис владеет своим набором сущностей.
🔹 Управление объявлениями
Ad, AdVersion, AdStatus.
🔹 Биллинг
Budget, Reservation, Transaction.
🔹 Публикации
PlatformAd, SyncStatus.
Никакой “общей БД на всех”.
Данные связаны по id (PK - первичным ключам).
Связь через брокеры + API.
———
4️⃣ По процессным границам
Границы сервисов можно выявить через группы сценариев, которые логически связаны и часто изменяются вместе.
🔹 Запуск рекламной кампании
Создание объявления, прохождение модерации, получение ERID, публикация на площадке, активация, запуск биллинга.
🔹 Управление кампанией
Приостановка и возобновление показов, изменение статуса, обновление параметров размещения.
🔹 Управление бюджетом
Начисление бюджета, резерв средств, списание, корректировки, возвраты.
———
5️⃣ По уровню нагрузки и SLA
Это уже архитектурная зрелость.
🔹 Сервис статистики
Высокая нагрузка на чтение, горизонтальное масштабирование.
🔹 Сервис публикаций
Много внешних API-вызовов, таймауты и задержки.
🔹 Биллинг
Повышенные требования к консистентности и надёжности.
———
Список микросервисов по каждой категории можно продолжить.
👉 Разные способы декомпозиции часто приводят к похожему набору сервисов.
Но основание для выделения сервиса должно быть зафиксировано в архитектурных принципах проекта.
Это поможет избежать неясностей и обеспечит гибкость при развитии проекта 🚀
#АрхитектураGA
Хорошая декомпозиция системы на микросервисы — это когда по каждому сервису понятно:
✔️ чем владеет (данные),
✔️ какие функции выполняет,
✔️ что он гарантирует (SLA),
✔️ и как реагирует на сбои.
Разберём 5 ключевых подходов к декомпозиции системы на микросервисы на примере проекта по управлению рекламой #AdFlowGA👇
———
1️⃣ По группам функций
Каждый микросервис объединяет логически связанные функции.
🔹 Сервис объявлений
Создание и редактирование креативов, версии, черновики, статусы.
🔹 ERID-сервис
Интеграция с ОРД, регистрация рекламы, хранение ERID, ретраи при ошибках.
🔹 Управление публикациями
Интеграции с рекламными API (VK, Telegram и др.), получение platformAdId.
🔹 Сервис биллинга
Резерв бюджета, списания, учёт показов, финансовая отчётность.
Подход понятный.
Но может игнорировать реальные доменные границы и различия в SLA.
———
2️⃣ По доменам (DDD — Bounded Context)
Выделяем ограниченные контексты с собственными правилами и моделями данных.
🔹 Домен “Управление объявлениями”
Креативы, статусы, версии, бизнес-правила переходов состояний.
🔹 Домен “Маркировка”
ERID, интеграция с ОРД, требования к отчётности, юридические ограничения.
🔹 Домен “Публикация”
Работа с API площадок, синхронизация статусов, дедупликация запросов.
🔹 Домен “Финансы”
Резервы, списания, корректировки, возвраты.
Важно:
разные домены = разные SLA и разные требования к отказоустойчивости.
———
3️⃣ По данным (Data Ownership)
Каждый сервис владеет своим набором сущностей.
🔹 Управление объявлениями
Ad, AdVersion, AdStatus.
🔹 Биллинг
Budget, Reservation, Transaction.
🔹 Публикации
PlatformAd, SyncStatus.
Никакой “общей БД на всех”.
Данные связаны по id (PK - первичным ключам).
Связь через брокеры + API.
———
4️⃣ По процессным границам
Границы сервисов можно выявить через группы сценариев, которые логически связаны и часто изменяются вместе.
🔹 Запуск рекламной кампании
Создание объявления, прохождение модерации, получение ERID, публикация на площадке, активация, запуск биллинга.
🔹 Управление кампанией
Приостановка и возобновление показов, изменение статуса, обновление параметров размещения.
🔹 Управление бюджетом
Начисление бюджета, резерв средств, списание, корректировки, возвраты.
———
5️⃣ По уровню нагрузки и SLA
Это уже архитектурная зрелость.
🔹 Сервис статистики
Высокая нагрузка на чтение, горизонтальное масштабирование.
🔹 Сервис публикаций
Много внешних API-вызовов, таймауты и задержки.
🔹 Биллинг
Повышенные требования к консистентности и надёжности.
———
Список микросервисов по каждой категории можно продолжить.
👉 Разные способы декомпозиции часто приводят к похожему набору сервисов.
Но основание для выделения сервиса должно быть зафиксировано в архитектурных принципах проекта.
Это поможет избежать неясностей и обеспечит гибкость при развитии проекта 🚀
#АрхитектураGA
❤12👍10🔥2
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
⏯ ЭПИЗОД 40:
Как системному аналитику найти работу в США и Европе: вакансии, навыки, шаги
Если вы уже гуглили “Работа системным аналитиком в США” или “Systems analyst в Европе”, то вы могли заметить странную вещь: вакансии есть, но названия, требования и ожидания часто отличаются от того, к чему привыкли в СНГ.
В этом эпизоде разбираем рынок, роли, навыки, документацию, интервью и английский, а в конце — пошаговая инструкция, как двигаться к офферу за пределами своей страны.
🔗 Сайт эпизода с обзором вакансий в США и Европе
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video
Сообщество системных аналитиков GetAnalyst — ваша идеальная база знаний для роста в карьере 🚀
Как системному аналитику найти работу в США и Европе: вакансии, навыки, шаги
Если вы уже гуглили “Работа системным аналитиком в США” или “Systems analyst в Европе”, то вы могли заметить странную вещь: вакансии есть, но названия, требования и ожидания часто отличаются от того, к чему привыкли в СНГ.
В этом эпизоде разбираем рынок, роли, навыки, документацию, интервью и английский, а в конце — пошаговая инструкция, как двигаться к офферу за пределами своей страны.
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video
Сообщество системных аналитиков GetAnalyst — ваша идеальная база знаний для роста в карьере 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥15🔥5🦄2❤1👍1
Говорят, идеальных мужчин не существует 👀
Это не так. Просто они бывают очень разными, и каждый по-своему сильный и прекрасный.
Кто-то сидит за ноутбуком и решает то, что для других выглядит как «что вообще происходит?» 😏
Кто-то держит на себе семью, работу, ответственность и слово.
👉 Мужчины — это про опору.
Про силу, интеллект, юмор, собранность и поступки.
Про умение защитить, поддержать, решить проблему и не потеряться в сложный момент.
И да, отдельно хочется выделить мужчин из IT ❤️🔥
👉 с вами всегда есть о чем поговорить - от жизни до технологий,
👉 и вам правда всегда хочется принести что-нибудь вкусное к компьютеру, пока вы заняты своими важными делами 🍪🍕🥗
Спасибо вам, мужчины, что вы есть.
За заботу, надежность, характер и то самое ощущение: «рядом — настоящий мужчина»!
Вы такие везде, как в работе, так и в жизни!
С 23 Февраля! Очень вами гордимся! 💙
👉 Девушки, давайте поздравим наших коллег-мужчин ❤️🔥❤️🔥❤️🔥 под этим постом + в комментариях 😊
С добром и теплом,
Екатерина Ананьева,
и команда GetAnalyst
Это не так. Просто они бывают очень разными, и каждый по-своему сильный и прекрасный.
Кто-то сидит за ноутбуком и решает то, что для других выглядит как «что вообще происходит?» 😏
Кто-то держит на себе семью, работу, ответственность и слово.
👉 Мужчины — это про опору.
Про силу, интеллект, юмор, собранность и поступки.
Про умение защитить, поддержать, решить проблему и не потеряться в сложный момент.
И да, отдельно хочется выделить мужчин из IT ❤️🔥
👉 с вами всегда есть о чем поговорить - от жизни до технологий,
👉 и вам правда всегда хочется принести что-нибудь вкусное к компьютеру, пока вы заняты своими важными делами 🍪🍕🥗
Спасибо вам, мужчины, что вы есть.
За заботу, надежность, характер и то самое ощущение: «рядом — настоящий мужчина»!
Вы такие везде, как в работе, так и в жизни!
С 23 Февраля! Очень вами гордимся! 💙
👉 Девушки, давайте поздравим наших коллег-мужчин ❤️🔥❤️🔥❤️🔥 под этим постом + в комментариях 😊
С добром и теплом,
Екатерина Ананьева,
и команда GetAnalyst
❤🔥53❤24🔥8😁1
This media is not supported in your browser
VIEW IN TELEGRAM
API Gateway (API-шлюз) — это единая точка входа для всех клиентских запросов к Backend.
Обычно используется в микросервисной архитектуре.
👉 Его главная функция — маршрутизация запросов.
Но, помимо этого, API Gateway предоставляет и другие важные функции.
Давайте последовательно разберём как он работает:
1️⃣ Первичная обработка запроса
Клиент отправляет запрос в API Gateway, а не напрямую к сервисам. Это обеспечивает централизованную точку входа в систему, а также упрощает интеграцию для клиента.
2️⃣ Валидация запроса
API Gateway проверяет корректность запроса.
Если формат нарушен — запрос отклоняется.
3️⃣ Проверка безопасности
Выполняется проверка по спискам разрешённых (allow-list) и запрещённых (deny-list) источников. Небезопасные запросы блокируются.
4️⃣ Аутентификация и авторизация
Проверяет токены и другие учетные данные. Гарантирует, что у клиента есть необходимые разрешения для доступа к запрашиваемым ресурсам.
5️⃣ Ограничение частоты запросов (Rate Limiting)
Если клиент превышает лимит запросов — они отклоняются с соответствующим ответом.
6️⃣ Маршрутизация к нужному сервису
На основе пути или других признаков API-шлюз определяет, какому микросервису должен быть направлен запрос.
7️⃣ Преобразование протоколов
При необходимости, преобразует запрос в нужный формат.
Например, если API Gateway принимает запрос в HTTP (REST API), то он может преобразовать его в gRPC для внутреннего микросервиса.
8️⃣ Агрегация ответов
Если ответ зависит от нескольких микросервисов, API Gateway собирает данные с каждого и формирует единый ответ.
9️⃣ Возврат ответа клиенту
Сформированный ответ возвращается клиенту в нужном формате и в установленный тайм-ауты.
🔟 Логирование, мониторинг, обработка ошибок и кэширование
На протяжении всего процесса обработки запроса.
❗️ Это такой же микросервис, как и сервис авторизации, сервис платежей и другие сервисы системы. На картинке к посту его можно также показывать синим прямоугольником.
API Gateway упрощает взаимодействие клиентов с распределённой системой и обеспечивает её безопасную и управляемую работу, выступая в роли централизованной точки входа.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥33❤9👍3🤔1