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
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👍2✍1👌1
ГЛОССАРИЙ СИСТЕМНОГО АНАЛИТИКА ИНФОРМАЦИОННЫХ СИСТЕМ
У нас получилось собрать обширный словарь терминов, который охватывает всё, что окружает системного аналитика: от ролей в компании и методологий разработки до технических терминов интеграций. Помимо официальных терминов мы добавили разговорные, потому что вряд ли вы услышите от коллеги, что тот «выгрузил локальные изменения на сервер» — скорее всего, он лаконично «запушил».
Как его использовать?
— Новичкам в профессии или в компании глоссарий поможет быстрее сориентироваться в профессиональном жаргоне: когда слышишь что-то вроде «Владелец продукта сказал задеплоить на прод» или «надо оформить MoSCoW», открываешь нужный раздел и всё проясняется.
— Можно взять наш глоссарий за основу и опубликовать в корпоративном конфлюенсе. Во-первых, это упростит онбординг новых коллег: вместо бесконечных расспросов «А что такое рефайнмент?» есть готовый «словарь», где все слова и пояснения собраны. Во-вторых, это будет единая «точка правды»: команды часто спорят, что значат «нефункционалки» или «альтернативные потоки». Теперь им можно просто сослаться на общую договорённость из глоссария.
И теперь мы обращаемся к вам: помогите нам его пополнять и исправлять. На основании ваших обсуждений мы дополним и исправим наш глоссарий, так наша подборка станет ещё полезнее.
Сегодняшняя тема:
«Развертывание» или «деплой» — процедура, с которой связан любой IT-проект. И в каждой компании своя терминология: кто-то «деплоит», кто-то «выкатывает на прод», кто-то «заливает обновления», а в ТЗ может стоять «развертывание системы на боевом сервере с учётом ограничений доступности». Короче, путаницы хватает, давайте её разберём.
Делитесь в комментариях официальными и разговорными терминами, которые использует ваша команда. Чем вы занимаетесь: «деплоите» или «выкатываете релиз»? Какая у вас бывает целевая среда: «продакшн» и «тестовый стенд»? Какими словами вы называете откат или отмену обновления? А, может, вы знаете, что такое непрерывная доставка или проброс портов?
Ждём ваши комментарии⬇️
У нас получилось собрать обширный словарь терминов, который охватывает всё, что окружает системного аналитика: от ролей в компании и методологий разработки до технических терминов интеграций. Помимо официальных терминов мы добавили разговорные, потому что вряд ли вы услышите от коллеги, что тот «выгрузил локальные изменения на сервер» — скорее всего, он лаконично «запушил».
Как его использовать?
— Новичкам в профессии или в компании глоссарий поможет быстрее сориентироваться в профессиональном жаргоне: когда слышишь что-то вроде «Владелец продукта сказал задеплоить на прод» или «надо оформить 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)
2️⃣ Разделяйте внутреннее и внешнее API
Ваш API должен быть гибким и независимым. Разделяйте:
— Внешнее API (для партнеров, мобильных приложений, клиентов)
— Внутреннее API (для взаимодействия между микросервисами)
3️⃣ Делайте API версионируемым
Без версионирования API разрыв обратной совместимости неизбежен
— Вводите версионирование сразу:
— Используйте backward-compatible изменения (добавление полей, а не изменение формата)
— Если API меняется кардинально, поддерживайте несколько версий
4️⃣ Используйте брокеры сообщений для событийных интеграций
Если в будущем ожидается много асинхронных процессов (уведомления, аналитика, платежи), проектируйте систему сразу с событийно-ориентированной архитектурой (EDA):
— Kafka, RabbitMQ, NATS — для передачи событий между сервисами
— Webhooks — для уведомлений внешних систем
На курсе «Архитектура ИТ-решения: Проектирование и реализация MVP» вы изучите принципы работы веб-приложений, научитесь проектировать и реализовывать двухзвенную, трехзвенную и EDA-архитектуры на открытом стеке (PostgreSQL, Kafka, Python).
Регистрация
#курс@systems_education #проектирование@systems_education #MVP@systems_education
Представьте: вы разработали 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
❤9✍1
Forwarded from Systems Design: онлайн-конференция по проектированию информационных систем для бизнеса
📣 Расписание готово!
На сайте конференции доступно расписание всех трёх потоков докладов, которые пройдут в первый день (12.04, сб)
Начнём мы в 9:00 МСК, закончим в 18:00 МСК. В каждом параллельном потоке вас будут ждать по 8 докладчиков. Вы уже сейчас можете планировать первый день конференции, отметив наиболее интересные для вас выступления.
Не переживайте, если возникнут накладки и у вас не получится посмотреть все понравившиеся доклады. После конференции будут доступны записи всех выступлений.
🚀 Встречаемся уже через неделю!
Подробнее о конференции здесь
Канал конференции @systems_design_online
#конференция@systems_education
На сайте конференции доступно расписание всех трёх потоков докладов, которые пройдут в первый день (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
Сохраняйте пост, чтобы потом не потерять!
🔹Курсы:
Системный анализ. Разработка требований и функциональное проектирование систем (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
Forwarded from Systems Design: онлайн-конференция по проектированию информационных систем для бизнеса
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
О докладе:
Успешные проекты требуют четкой, актуальной и хорошо структурированной документации. Однако её создание и поддержка — сложный и трудозатратный процесс.
Мы рассмотрим, как искусственный интеллект помогает:
— Генерировать эпики, юзер-стори и тест-кейсы на основе требований
— Поддерживать документацию в актуальном состоянии
— Обеспечивать согласованность терминологии и удобочитаемость
— Оптимизировать тестирование с помощью AI-генерируемых сценариев
— Ускорять написание кода разработчиками, улучшать комментарии, документировать существующий код и API
Мы поговорим о ключевых AI-инструментах, такие как ChatGPT, Atlassian Intelligence и GitHub Copilot, которые делают техническую документацию более точной, быстрой в создании и лёгкой в сопровождении. ИИ — это не замена человеку, а мощное средство автоматизации, позволяющее командам сосредоточиться на разработке, а не на рутинных задачах.
Подробнее о конференции здесь
Канал конференции @systems_design_online
#конференция@systems_education
✍2❤2
Forwarded from Systems Design: онлайн-конференция по проектированию информационных систем для бизнеса
🎥 Выложили запись доклада Евгения Лыкова с конференции 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
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
YouTube
Проектирование медицинского ассистивного ПО в условиях высокой неопределённости • Евгений Лыков
На онлайн-конференции Systems Design 2024 ex-CTO и ведущий программный инженер Visionis Евгений Лыков представил доклад, поделившись опытом разработки стартапа EyeDoo, который позволяет управлять компьютером с помощью взгляда. В своём выступлении он подробно…
🎄1
Опубликовали перевод 5 главы книги «Основы инженерии данных» на тему «Генерация данных в исходных системах»
В этой главе рассказывается о первом этапе жизненного цикла инженерии данных — генерации данных в исходных системах. Авторы описывают, как и где возникают данные (например, в базах данных приложений, через API, логи, потоковые платформы), а также дают обзор ключевых понятий, которые важно учитывать инженеру данных (OLTP, OLAP, ACID, CDC и др.). Подчёркивается важность понимания природы и особенностей исходных систем, взаимодействия с командами, которые их поддерживают, и учёта фоновых процессов (безопасность, управление данными, DevOps, архитектура). Главная идея — научиться правильно «забирать» данные из источников, не нарушая работу систем, и понимать, как их особенности влияют на качество и дальнейшую обработку этих данных.
Содержание главы:
1. Источники данных: Как создаются данные?
2. Исходные системы: Основные идеи
3. Практические сведения об исходных системах
4. С кем вы будете работать
5. Фоновые процессы и их влияние на исходные системы
Почитать можно тут
#статья@systems_education
В этой главе рассказывается о первом этапе жизненного цикла инженерии данных — генерации данных в исходных системах. Авторы описывают, как и где возникают данные (например, в базах данных приложений, через API, логи, потоковые платформы), а также дают обзор ключевых понятий, которые важно учитывать инженеру данных (OLTP, OLAP, ACID, CDC и др.). Подчёркивается важность понимания природы и особенностей исходных систем, взаимодействия с командами, которые их поддерживают, и учёта фоновых процессов (безопасность, управление данными, DevOps, архитектура). Главная идея — научиться правильно «забирать» данные из источников, не нарушая работу систем, и понимать, как их особенности влияют на качество и дальнейшую обработку этих данных.
Содержание главы:
1. Источники данных: Как создаются данные?
2. Исходные системы: Основные идеи
3. Практические сведения об исходных системах
4. С кем вы будете работать
5. Фоновые процессы и их влияние на исходные системы
Почитать можно тут
#статья@systems_education
systems.education
Глава 5. Генерация данных в исходных системах. Джо Рис, Мэтт Хоусли. Основы инженерии данных
Автор: Джо Рис, Мэтт Хоусли [перевод]
🔥3
Forwarded from Systems Design: онлайн-конференция по проектированию информационных систем для бизнеса
13 апреля (вс) в рамках конференции «Systems Design Online» пройдёт воркшоп «Принятие и документирование архитектурных решений»
🔹Воркшоп будет полезен:
— Системным аналитикам уровня Middle- (и выше)
— Специалистам, занимающиеся проектированием и интеграцией сервисов
— Архитекторам решений
🔹На воркшопе вы научитесь:
— Осознанно подходить к проектированию решений
— Фиксировать архитектурные решения, используя ADR (Architectural Decision Records)
— Работать с несколькими вариантами архитектурных решений, анализировать их плюсы и минусы
— Повысить уровень взаимодействия в команде при обсуждении архитектуры
🔹Программа воркшопа:
1. Введение
2. Первая итерация
— Участники работают в группах, решают задачу
— Оформляют архитектурные решения
3. Разбор первой итерации
— Группы меняются результатами
— Анализируют чужие решения, вносят правки
4. Вторая итерация
— Уточнение и адаптация решений
— Документирование принятых решений
5. Финальный разбор
— Обсуждение типичных проблем
— Выводы, рекомендации
🔹Для успешного прохождения воркшопа необходимо:
— Иметь базовое понимание проектирования информационных систем
— Опыт участия в принятии решений по архитектуре ПО
— Интерес к процессам интеграции сервисов
👥 Ведущий — Максим Шаломович, Архитектор Решений в крупных корпоративных и государственных проектных инициативах
Регистрация на воркшоп
Подробнее о докладах и других воркшопах конференции здесь
Канал конференции @systems_design_online
#выступления@systems_education
🔹Воркшоп будет полезен:
— Системным аналитикам уровня 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
Forwarded from Systems Design: онлайн-конференция по проектированию информационных систем для бизнеса
🛰 Михаил Першин, Lead Backend Engineer в HaHa Inc и Архитектор криптоприложений, выступит на третьей конференции Systems Design Online с докладом на тему «1000 -> 500к: успех или провал?»
О докладе:
Как подготовиться к ожидаемому взрывному росту:
— Проактивные меры — куда смотреть, а куда нет
— Технологические решения — как поднять то, что уже лежит
— Процессный подход — как и что организовывать, а что можно пропустить
— Ментальный настрой — как совладать с паникой в команде и коммьюнити
Подробнее о конференции здесь
Канал конференции @systems_design_online
#конференция@systems_education
О докладе:
Как подготовиться к ожидаемому взрывному росту:
— Проактивные меры — куда смотреть, а куда нет
— Технологические решения — как поднять то, что уже лежит
— Процессный подход — как и что организовывать, а что можно пропустить
— Ментальный настрой — как совладать с паникой в команде и коммьюнити
Подробнее о конференции здесь
Канал конференции @systems_design_online
#конференция@systems_education
❤1
Алина Богачёва, Архитектор бизнес-решений в области финансов, CEO и CFO Systems.Education выступит на IT Global Meetup #17 с докладом на тему «Алгоритм проектирования бизнес-алгоритмов»
Алина расскажет, как с помощью четырёхшагового алгоритма проектировать бизнес-процессы так, чтобы не пропустить негативные или альтернативные ветви. Этот подход помогает формализовать логику и избежать дорогих ошибок, возникающих при неполном учёте исключительных случаев.
Подробности и регистрация
❗️Участие бесплатное❗️
🗓 13 апреля 2025
📍 Азимут отель Санкт-Петербург Лермонтовский пр. 43/1
Алина расскажет, как с помощью четырёхшагового алгоритма проектировать бизнес-процессы так, чтобы не пропустить негативные или альтернативные ветви. Этот подход помогает формализовать логику и избежать дорогих ошибок, возникающих при неполном учёте исключительных случаев.
Подробности и регистрация
❗️Участие бесплатное❗️
🗓 13 апреля 2025
📍 Азимут отель Санкт-Петербург Лермонтовский пр. 43/1
piter-united.ru
ITGM Весна 2025
Весенний слет ИТ-сообществ Петербурга
❤2👍1
Как найти узкие места до того, как они появятся в проде
Если у вас есть ощущение, что диаграммы последовательности — это просто иллюстрация цепочки вызовов, то держитесь: вы их недооцениваете!
🖥 Sequence Diagram — это больше, чем схема взаимодействия. Это диаграмма профилактики системных проблем.
Где обычно прячутся узкие места?
— Избыточные вызовы
— Слишком долгая цепочка
— Асинхронные ловушки. Выглядит как «вызвал и забыл», а по факту — потерянные события
— Дублирование логики. Когда два сервиса делают почти одно и то же — и оба об этом не знают
— Неразделённые ответственности
Sequence Diagram в таких случаях помогает:
— Визуализацией сценариев end-to-end
— Считает шаги. Сколько взаимодействий нужно, чтобы выполнить одно действие?
— Оценивает зависимости. Что будет, если один сервис «упадёт»? Диаграмма покажет уязвимые звенья.
— Ищет циклы. Loop-блоки на диаграмме часто указывают на неэффективные алгоритмы.
— Видит, где нужна буферизация. Особенно в системах с высоким трафиком — очередь сообщений должна быть видна на диаграмме.
Если ты еще не знаком с данной UML-диаграммой, приглашаем на воркшоп «UML-диаграммы последовательности для аналитика: ликбез и примеры использования», на котором ты под руководством эксперта научишься строить Sequence диаграммы, читать их и использовать для проектирования поведения систем.
Регистрация
#воркшоп@systems_education #uml@systems_education #sequence@systems_education
Если у вас есть ощущение, что диаграммы последовательности — это просто иллюстрация цепочки вызовов, то держитесь: вы их недооцениваете!
Где обычно прячутся узкие места?
— Избыточные вызовы
— Слишком долгая цепочка
— Асинхронные ловушки. Выглядит как «вызвал и забыл», а по факту — потерянные события
— Дублирование логики. Когда два сервиса делают почти одно и то же — и оба об этом не знают
— Неразделённые ответственности
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
Forwarded from Systems Design: онлайн-конференция по проектированию информационных систем для бизнеса
Остаются считанные места на мастер-класс «Архитектурные решения и AI», который пройдет во второй день конференции «Systems Design Online»
Архитекторы должны принимать архитектурные решения, проверять уже существующие, документировать архитектуру и обновлять архитектурные документы. Современные системы искуственного интеллекта могут в этом сильно помочь. На мастер-классе мы разберёмся, какие именно инструменты для этого нужны и как их применить для упомянутых активностей.
🔹Мастер-класс будет полезен:
— Старшим инженерам
— Тимлидам
— Архитекторам
— Специалистам, которые принимают архитектурные решения
🔹Для успешного прохождения мастер-класс необходимо:
— Заранее установить софт: Llama (локальный столяр для моделей)
🔹Что узнают участники мастер-класса:
— Разные способы применения больших языковых моделей
— Как анализировать текущие архитектурные решения
— Как анализировать архитектурные схемы с помощью LLM
— Как создавать документацию к архитектурным решениям
👥 Ведущий — Владимир Иванов, Старший менеджер по разработке в Bolt, Ведущий тг-канала Architecture Weekly @architectureweekly
Регистрация на мастер-класс
Подробнее о докладах и других воркшопах конференции здесь
Канал конференции @systems_design_online
#выступления@systems_education
Архитекторы должны принимать архитектурные решения, проверять уже существующие, документировать архитектуру и обновлять архитектурные документы. Современные системы искуственного интеллекта могут в этом сильно помочь. На мастер-классе мы разберёмся, какие именно инструменты для этого нужны и как их применить для упомянутых активностей.
🔹Мастер-класс будет полезен:
— Старшим инженерам
— Тимлидам
— Архитекторам
— Специалистам, которые принимают архитектурные решения
🔹Для успешного прохождения мастер-класс необходимо:
— Заранее установить софт: 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
Что такое информационная система?
Информационная система (ИС) — это совокупность взаимосвязанных компонентов (людей, процессов, аппаратного и программного обеспечения), предназначенных для сбора, хранения, обработки и передачи данных. Основная задача ИС — обеспечить доступ к нужной информации в нужный момент и упростить принятие решений.
Что такое база данных и зачем она нужна в ИС?
База данных (БД) — это структурированное хранилище, где аккумулируется вся необходимая для работы системы информация. Правильно настроенная БД гарантирует:
— Надёжное хранение больших объёмов данных
— Быстрый поиск и обновление информации
— Поддержание целостности и согласованности данных
Организации могут работать с различными объёмами и типами данных (текстовые, мультимедийные, метрические). Именно поэтому существует множество видов систем управления базами данных (СУБД): реляционные, документно-ориентированные, графовые и т.д. При этом на одном и том же наборе данных разные СУБД могут решать принципиально разные задачи, поэтому крайне важно выбрать правильную СУБД, способную обеспечить требуемые показатели производительности системы.
Чтобы доступ к информации был быстрым, её необходимо структурировать в БД по определённым правилам. В этом и заключается основной принцип проектирования баз данных, который позволяет избежать дублирования и потери данных, а также упростить их анализ и дальнейшее развитие системы.
⚙️ С ЧЕГО НАЧАТЬ ПРОЕКТИРОВАНИЕ БД?
Правильный старт — моделирование предметной области, в которой функционирует ИС. Это позволит еще на ранних этапах проектирования понять взаимосвязь объектов и событий домена. Этот процесс включает:
— Определение основных объектов (сущностей) предметной области;
— Определение их характеристик (атрибутов), необходимых для работы системы.
Именно такой подход к проектированию базы данных позволяет создать надёжную основу для развития и масштабирования информационной системы, соответствующей актуальным потребностям бизнеса.
Изучите, как подобрать оптимальную СУБД для работы с большими данными, ознакомившись со статьёй из нашей базы знаний по ссылке
Для повышения квалификации системных аналитиков и совершенствования умений проектирования баз данных, мы предлагаем принять участие в воркшопе «Моделирование предметной области и Проектирование базы данных»
Регистрация
#воркшоп@systems_education #базы_данных@systems_education #моделирование@systems_education
❤2