Telegram Web Link
REST API для высоконагруженных систем: как выдерживать миллионы запросов в секунду?

REST API должен быть не просто удобным, но и эффективным. Однако стандартная реализация REST API не всегда справляется с высокой нагрузкой.

Как ускорить REST API и выдержать нагрузку?

🔹 Кэширование: не заставляйте сервер работать лишний раз
Кэширование позволяет повторно использовать ранее рассчитанные данные, не нагружая сервер.

— Кэширование на клиенте — браузеры и мобильные приложения могут хранить часто используемые данные, чтобы не делать запросы заново.
— HTTP-кэширование — заголовки Cache-Control и ETag позволяют серверам и прокси-кэшам хранить ответы.
— Redis/Memcached — серверное кэширование часто запрашиваемых данных в памяти снижает нагрузку на базу данных.

🔹 Сжатие данных: уменьшите размер ответа API

Чем меньше данных передаётся по сети, тем быстрее работает API

— Gzip, Brotli — сжатие HTTP-ответов уменьшает трафик в 3-5 раз.
— JSON без лишних полей — вместо отправки {"name": "iPhone", "price": 999, "description": "Powerful phone"} можно оставить только нужные поля.
— Binарные форматы — gRPC или Protobuf позволяют передавать данные эффективнее, чем JSON.

🔹 Пагинация: не перегружайте API ненужными данными

Без пагинации API может отдавать тысячи записей за один запрос, что приводит к:
— Долгому времени обработки
— Избыточному расходу памяти
— Перегрузке сервера

Как сделать правильно?
— Пагинация с limit и offset (/users?limit=50&offset=100)
— Курсорная пагинация — эффективнее при больших объёмах данных (/users?cursor=abcd1234)
— API, отдающее только изменённые данные (/updates?since=2024-03-10)

🔹 Асинхронные операции: не заставляйте клиентов ждать
— Очереди сообщений (RabbitMQ, Kafka, NATS) — запрос ставится в очередь, а клиент получает job_id
— Webhook’и — API отправляет уведомление, когда работа завершена
— Poll-подход — клиент периодически проверяет статус задачи (/report/status?id=123)

🔹 Балансировка нагрузки: распределите запросы по серверам

Когда запросов слишком много, одного сервера уже недостаточно. Решение — балансировка нагрузки:
— Reverse proxy (NGINX, HAProxy) — равномерно распределяет запросы между несколькими серверами
— Auto Scaling — при увеличении нагрузки автоматически добавляются новые серверы (AWS, Kubernetes)
— Rate Limiting — ограничение запросов (1000 rps на пользователя) защищает API от перегрузок и атак

На воркшопе «Проектирование интеграции с REST API» вы под руководством эксперта проанализируете процесс взаимодействия систем, потоки данных, опишете REST-like API и поймёте, как аналитик решает интеграционные задачи.

Регистрация

#воркшоп@systems_education
4👍21👌1
ГЛОССАРИЙ СИСТЕМНОГО АНАЛИТИКА ИНФОРМАЦИОННЫХ СИСТЕМ

У нас получилось собрать обширный словарь терминов, который охватывает всё, что окружает системного аналитика: от ролей в компании и методологий разработки до технических терминов интеграций. Помимо официальных терминов мы добавили разговорные, потому что вряд ли вы услышите от коллеги, что тот «выгрузил локальные изменения на сервер» — скорее всего, он лаконично «запушил».

Как его использовать?
— Новичкам в профессии или в компании глоссарий поможет быстрее сориентироваться в профессиональном жаргоне: когда слышишь что-то вроде «Владелец продукта сказал задеплоить на прод» или «надо оформить MoSCoW», открываешь нужный раздел и всё проясняется.
— Можно взять наш глоссарий за основу и опубликовать в корпоративном конфлюенсе. Во-первых, это упростит онбординг новых коллег: вместо бесконечных расспросов «А что такое рефайнмент?» есть готовый «словарь», где все слова и пояснения собраны. Во-вторых, это будет единая «точка правды»: команды часто спорят, что значат «нефункционалки» или «альтернативные потоки». Теперь им можно просто сослаться на общую договорённость из глоссария.

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

Сегодняшняя тема:
«Как мы развёртываем приложение или сервис на целевой среде»


«Развертывание» или «деплой» — процедура, с которой связан любой IT-проект. И в каждой компании своя терминология: кто-то «деплоит», кто-то «выкатывает на прод», кто-то «заливает обновления», а в ТЗ может стоять «развертывание системы на боевом сервере с учётом ограничений доступности». Короче, путаницы хватает, давайте её разберём.

Делитесь в комментариях официальными и разговорными терминами, которые использует ваша команда. Чем вы занимаетесь: «деплоите» или «выкатываете релиз»? Какая у вас бывает целевая среда: «продакшн» и «тестовый стенд»? Какими словами вы называете откат или отмену обновления? А, может, вы знаете, что такое непрерывная доставка или проброс портов?

Ждём ваши комментарии⬇️
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15
Как избежать интеграционного ада при проектировании MVP?

Представьте: вы разработали MVP, пользователи довольны, метрики растут. Но вот приходит момент, когда нужно интегрировать платежную систему, подключить CRM или запустить мобильное приложение… И тут оказывается, что API в вашем MVP нет, либо оно хаотично, либо привязано к внутренней логике так, что любое обновление ломает весь сервис.

Почему важно учитывать API-интеграции еще на этапе проектирования MVP?
MVP — это не просто тестовая версия продукта, это основа, на которой будет строиться дальнейшая система. Ошибки в архитектуре интеграций могут:
— Замедлить масштабирование и развитие продукта
— Увеличить затраты на поддержку и разработку
— Привести к сложным рефакторингам и переработке архитектуры

Как этого избежать? Использовать лучшие практики проектирования API в MVP. Давайте разберем ключевые принципы.

1️⃣ Проектируйте API снаружи внутрь

Многие команды сначала создают бизнес-логику, а API добавляют потом, «как получится». В итоге API становится неуклюжим и неудобным. Вместо этого:
— Определите, какие интеграции потребуются в будущем (например, платежи, аналитика, внешние сервисы)
— Используйте API-first подход — сначала проектируйте API, а потом код
— Документируйте API сразу (OpenAPI/Swagger)

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


2️⃣ Разделяйте внутреннее и внешнее API

Ваш API должен быть гибким и независимым. Разделяйте:
— Внешнее API (для партнеров, мобильных приложений, клиентов)
— Внутреннее API (для взаимодействия между микросервисами)

3️⃣ Делайте API версионируемым

Без версионирования API разрыв обратной совместимости неизбежен
— Вводите версионирование сразу: https://api.example.com/v1/orders
— Используйте backward-compatible изменения (добавление полей, а не изменение формата)
— Если API меняется кардинально, поддерживайте несколько версий

Пример: В стартапе финтех-решений изменение структуры JSON привело к сбоям у клиентов. После внедрения v2 API с backward compatibility бизнес избежал проблем.


4️⃣ Используйте брокеры сообщений для событийных интеграций

Если в будущем ожидается много асинхронных процессов (уведомления, аналитика, платежи), проектируйте систему сразу с событийно-ориентированной архитектурой (EDA):
— Kafka, RabbitMQ, NATS — для передачи событий между сервисами
— Webhooks — для уведомлений внешних систем

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


На курсе «Архитектура ИТ-решения: Проектирование и реализация MVP» вы изучите принципы работы веб-приложений, научитесь проектировать и реализовывать двухзвенную, трехзвенную и EDA-архитектуры на открытом стеке (PostgreSQL, Kafka, Python).

Регистрация

#курс@systems_education #проектирование@systems_education #MVP@systems_education
91
📣 Расписание готово!

На сайте конференции доступно расписание всех трёх потоков докладов, которые пройдут в первый день (12.04, сб)

Начнём мы в 9:00 МСК, закончим в 18:00 МСК. В каждом параллельном потоке вас будут ждать по 8 докладчиков. Вы уже сейчас можете планировать первый день конференции, отметив наиболее интересные для вас выступления.

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

🚀 Встречаемся уже через неделю!

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Дайджест курсов и воркшопов школы на апрель 🌺

Сохраняйте пост, чтобы потом не потерять!


🔹Курсы:

Системный анализ. Разработка требований и функциональное проектирование систем (19 Апреля-11 Мая)

Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения
Регистрация

🔹Воркшопы:

1️⃣ BPMN для людей: основы самой популярной нотации для описания бизнес-процессов (с 8 апреля)

Воркшоп для ИТ-специалистов, которые хотят научиться описывать логику выполнения бизнес-процессов с помощью формальной нотации — BPMN
Регистрация

2️⃣ Проектирование DWH по методологии Data Vault (с 16 апреля)

Data Vault, методология проектирования DWH, проще якорной модели (Anchor Modeling), но также обладает высокой гибкостью и лучше подается дополнению и расширению по сравнению с классическими звёздными схемами по Кимбалу и Инмону
Регистрация

3️⃣ Моделирование предметной области и Проектирование базы данных (21 апреля)

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

4️⃣ UML-диаграммы последовательности для аналитика: ликбез и примеры использования (23 апреля)

На воркшопе за 3 часа вы построите sequence диаграммы и убедитесь что:
— Cтроить sequence диаграммы несложно
— UML диаграммы удобно читать и легко понимать
— UML — отличный инструмент проектирования поведения систем
Регистрация

5️⃣ Проектирование интеграции с REST API (с 26 апреля)

Воркшоп будет полезен тем, кто хочет:
— познакомиться с REST API
— научиться проектировать интеграцию «с нуля»
— описывать REST-интерфейсы в виде, пригодном для разработки
Регистрация

#дайджест@systems_education
1👍1
Media is too big
VIEW IN TELEGRAM
🛰 Виталий Щур, Lead/Senior QA, выступит на третьей конференции Systems Design Online с докладом на тему «Революция в технической документации с помощью ИИ»

О докладе:
Успешные проекты требуют четкой, актуальной и хорошо структурированной документации. Однако её создание и поддержка — сложный и трудозатратный процесс.
Мы рассмотрим, как искусственный интеллект помогает:
— Генерировать эпики, юзер-стори и тест-кейсы на основе требований
— Поддерживать документацию в актуальном состоянии
— Обеспечивать согласованность терминологии и удобочитаемость
— Оптимизировать тестирование с помощью AI-генерируемых сценариев
— Ускорять написание кода разработчиками, улучшать комментарии, документировать существующий код и API

Мы поговорим о ключевых AI-инструментах, такие как ChatGPT, Atlassian Intelligence и GitHub Copilot, которые делают техническую документацию более точной, быстрой в создании и лёгкой в сопровождении. ИИ — это не замена человеку, а мощное средство автоматизации, позволяющее командам сосредоточиться на разработке, а не на рутинных задачах.

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education
22
🎥 Выложили запись доклада Евгения Лыкова с конференции Systems Design 24 на тему «Проектирование медицинского ассистивного ПО в условиях высокой неопределённости»

Ex-CTO и ведущий программный инженер Visionis Евгений Лыков представил доклад, поделившись опытом разработки стартапа EyeDoo, который позволяет управлять компьютером с помощью взгляда. В своём выступлении он подробно рассмотрел ключевые аспекты, включая трудности проектирования, поиск точек опоры, выбор платформы и языка, а также этические вопросы, подчеркнув важность гибкости и адаптации в условиях неопределённости.

Тайм-код доклада:
00:00 О спикере
01:35 Трудности с проектированием
03:44 Описание стартапа EyeDoo - управление компьютером при помощь взгляда
06:37 Неопределённости стартапа
09:50 Поиск точек опоры
12:01 Платформа
15:08 Язык
17:47 Система
19:38 Версионность
21:27 Продукт
24:45 Вспомогательные технологии
26:44 Этическая составляющая
28:01 Выводы

Посмотреть можно на нашем You-Tube канале

🚀 12-13 апреля состоится третья конференция Systems Design Online

Конференция Systems Design Online будет интересна:
— разработчикам и аналитикам
— архитекторам и руководителям ИТ-проектов
— всем, кто стремится повышать эффективность бизнес-процессов при помощи современных технологических решений

Подробнее о конференции здесь
Канал конференции @systems_design_online

#выступления@systems_education
🎄1
Опубликовали перевод 5 главы книги «Основы инженерии данных» на тему «Генерация данных в исходных системах»

В этой главе рассказывается о первом этапе жизненного цикла инженерии данных — генерации данных в исходных системах. Авторы описывают, как и где возникают данные (например, в базах данных приложений, через API, логи, потоковые платформы), а также дают обзор ключевых понятий, которые важно учитывать инженеру данных (OLTP, OLAP, ACID, CDC и др.). Подчёркивается важность понимания природы и особенностей исходных систем, взаимодействия с командами, которые их поддерживают, и учёта фоновых процессов (безопасность, управление данными, DevOps, архитектура). Главная идея — научиться правильно «забирать» данные из источников, не нарушая работу систем, и понимать, как их особенности влияют на качество и дальнейшую обработку этих данных.

Содержание главы:
1. Источники данных: Как создаются данные?
2. Исходные системы: Основные идеи
3. Практические сведения об исходных системах
4. С кем вы будете работать
5. Фоновые процессы и их влияние на исходные системы

Почитать можно тут

#статья@systems_education
🔥3
13 апреля (вс) в рамках конференции «Systems Design Online» пройдёт воркшоп «Принятие и документирование архитектурных решений»

🔹Воркшоп будет полезен:
— Системным аналитикам уровня Middle- (и выше)
— Специалистам, занимающиеся проектированием и интеграцией сервисов
— Архитекторам решений

🔹На воркшопе вы научитесь:
— Осознанно подходить к проектированию решений
— Фиксировать архитектурные решения, используя ADR (Architectural Decision Records)
— Работать с несколькими вариантами архитектурных решений, анализировать их плюсы и минусы
— Повысить уровень взаимодействия в команде при обсуждении архитектуры

🔹Программа воркшопа:
1. Введение 
2. Первая итерация
— Участники работают в группах, решают задачу
— Оформляют архитектурные решения
3. Разбор первой итерации
— Группы меняются результатами
— Анализируют чужие решения, вносят правки
4. Вторая итерация
— Уточнение и адаптация решений
— Документирование принятых решений
5. Финальный разбор
— Обсуждение типичных проблем
— Выводы, рекомендации

🔹Для успешного прохождения воркшопа необходимо:
— Иметь базовое понимание проектирования информационных систем
— Опыт участия в принятии решений по архитектуре ПО
— Интерес к процессам интеграции сервисов

🗓 Пройдёт воркшоп 13 апреля (вс), 16:00-18:00 МСК

👥 Ведущий — Максим Шаломович, Архитектор Решений в крупных корпоративных и государственных проектных инициативах

Регистрация на воркшоп
Подробнее о докладах и других воркшопах конференции здесь
Канал конференции @systems_design_online

#выступления@systems_education
Please open Telegram to view this post
VIEW IN TELEGRAM
1
🛰 Михаил Першин, Lead Backend Engineer в HaHa Inc и Архитектор криптоприложений, выступит на третьей конференции Systems Design Online с докладом на тему «1000 -> 500к: успех или провал?»

О докладе:
Как подготовиться к ожидаемому взрывному росту:
— Проактивные меры — куда смотреть, а куда нет
— Технологические решения — как поднять то, что уже лежит
— Процессный подход — как и что организовывать, а что можно пропустить
— Ментальный настрой — как совладать с паникой в команде и коммьюнити

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education
1
Алина Богачёва, Архитектор бизнес-решений в области финансов, CEO и CFO Systems.Education выступит на IT Global Meetup #17 с докладом на тему «Алгоритм проектирования бизнес-алгоритмов»

Алина расскажет, как с помощью четырёхшагового алгоритма проектировать бизнес-процессы так, чтобы не пропустить негативные или альтернативные ветви. Этот подход помогает формализовать логику и избежать дорогих ошибок, возникающих при неполном учёте исключительных случаев.

Подробности и регистрация
❗️Участие бесплатное❗️

🗓 13 апреля 2025

📍 Азимут отель Санкт-Петербург Лермонтовский пр. 43/1
2👍1
Как найти узкие места до того, как они появятся в проде

Если у вас есть ощущение, что диаграммы последовательности — это просто иллюстрация цепочки вызовов, то держитесь: вы их недооцениваете!

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

Где обычно прячутся узкие места?
— Избыточные вызовы
— Слишком долгая цепочка
— Асинхронные ловушки. Выглядит как «вызвал и забыл», а по факту — потерянные события
— Дублирование логики. Когда два сервиса делают почти одно и то же — и оба об этом не знают
— Неразделённые ответственности

Sequence Diagram в таких случаях помогает:
— Визуализацией сценариев end-to-end
— Считает шаги. Сколько взаимодействий нужно, чтобы выполнить одно действие?
— Оценивает зависимости. Что будет, если один сервис «упадёт»? Диаграмма покажет уязвимые звенья.
— Ищет циклы. Loop-блоки на диаграмме часто указывают на неэффективные алгоритмы.
— Видит, где нужна буферизация. Особенно в системах с высоким трафиком — очередь сообщений должна быть видна на диаграмме.

Если ты еще не знаком с данной UML-диаграммой, приглашаем на воркшоп «UML-диаграммы последовательности для аналитика: ликбез и примеры использования», на котором ты под руководством эксперта научишься строить Sequence диаграммы, читать их и использовать для проектирования поведения систем.

Регистрация

#воркшоп@systems_education #uml@systems_education #sequence@systems_education
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
5
Остаются считанные места на мастер-класс «Архитектурные решения и AI», который пройдет во второй день конференции «Systems Design Online»

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

🔹Мастер-класс будет полезен:
— Старшим инженерам
— Тимлидам
— Архитекторам
— Специалистам, которые принимают архитектурные решения

🔹Для успешного прохождения мастер-класс необходимо:
— Заранее установить софт: Llama (локальный столяр для моделей)

🔹Что узнают участники мастер-класса:
— Разные способы применения больших языковых моделей
— Как анализировать текущие архитектурные решения
— Как анализировать архитектурные схемы с помощью LLM
— Как создавать документацию к архитектурным решениям

🗓 Пройдёт мастер-класс 13 апреля (вс), 11:00-13:00 МСК

👥 Ведущий — Владимир Иванов, Старший менеджер по разработке в Bolt, Ведущий тг-канала Architecture Weekly @architectureweekly

Регистрация на мастер-класс
Подробнее о докладах и других воркшопах конференции здесь
Канал конференции @systems_design_online

#выступления@systems_education
Please open Telegram to view this post
VIEW IN TELEGRAM
1
База данных — основа любой информационной системы

Что такое информационная система?

Информационная система (ИС) — это совокупность взаимосвязанных компонентов (людей, процессов, аппаратного и программного обеспечения), предназначенных для сбора, хранения, обработки и передачи данных. Основная задача ИС — обеспечить доступ к нужной информации в нужный момент и упростить принятие решений.

Что такое база данных и зачем она нужна в ИС?

База данных (БД) — это структурированное хранилище, где аккумулируется вся необходимая для работы системы информация. Правильно настроенная БД гарантирует:
— Надёжное хранение больших объёмов данных
— Быстрый поиск и обновление информации
— Поддержание целостности и согласованности данных

Организации могут работать с различными объёмами и типами данных (текстовые, мультимедийные, метрические). Именно поэтому существует множество видов систем управления базами данных (СУБД): реляционные, документно-ориентированные, графовые и т.д. При этом на одном и том же наборе данных разные СУБД могут решать принципиально разные задачи, поэтому крайне важно выбрать правильную СУБД, способную обеспечить требуемые показатели производительности системы.

Чтобы доступ к информации был быстрым, её необходимо структурировать в БД по определённым правилам. В этом и заключается основной принцип проектирования баз данных, который позволяет избежать дублирования и потери данных, а также упростить их анализ и дальнейшее развитие системы.

⚙️ С ЧЕГО НАЧАТЬ ПРОЕКТИРОВАНИЕ БД?

Правильный старт — моделирование предметной области, в которой функционирует ИС. Это позволит еще на ранних этапах проектирования понять взаимосвязь объектов и событий домена. Этот процесс включает:
— Определение основных объектов (сущностей) предметной области;
— Определение их характеристик (атрибутов), необходимых для работы системы.

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

Изучите, как подобрать оптимальную СУБД для работы с большими данными, ознакомившись со статьёй из нашей базы знаний по ссылке

Для повышения квалификации системных аналитиков и совершенствования умений проектирования баз данных, мы предлагаем принять участие в воркшопе «Моделирование предметной области и Проектирование базы данных»
Регистрация

#воркшоп@systems_education #базы_данных@systems_education #моделирование@systems_education
2
2025/07/09 14:04:56
Back to Top
HTML Embed Code: