⚡️ Здравствуйте, Дорогие подписчики!
Представляем вашему вниманию подборку полезных каналов в сфере «Наука и образование» 🔥
Будем очень рады, если вы найдете для себя, что-нибудь полезное.
❗️Ссылка на папку:
https://t.me/addlist/sYIYFfnHbeExZDc6
Представляем вашему вниманию подборку полезных каналов в сфере «Наука и образование» 🔥
Будем очень рады, если вы найдете для себя, что-нибудь полезное.
❗️Ссылка на папку:
https://t.me/addlist/sYIYFfnHbeExZDc6
👍1
4684. Команда разрабатывает мобильное приложение доставки еды. При оформлении заказа нужно:
Создать заказ в БД
Отправить пуш-уведомление курьеру Обновить баланс бонусов клиента Как правильно спроектировать интеграцию?
Создать заказ в БД
Отправить пуш-уведомление курьеру Обновить баланс бонусов клиента Как правильно спроектировать интеграцию?
Anonymous Quiz
52%
Создать заказ → сразу ответить клиенту → асинхронно выполнить пуш и бонусы
13%
Выполнить всё синхронно в одной транзакции: заказ → пуш → бонусы
11%
Сначала отправить пуш, после успеха создать заказ и начислить бонусы
23%
Использовать распределенную транзакцию (2PC) для всех трех операций
👩🏫Объяснение:
Паттерн «Асинхронное завершение фоновых задач» критически важен для пользовательского опыта. Клиент ждет подтверждения заказа мгновенно, а технические детали (уведомление курьера, бонусы) могут быть выполнены после ответа.
Почему B — правильно:
✅ Скорость ответа клиенту — главное требование выполнено
✅ Устойчивость к сбоям — падение сервиса пушек не сорвет оформление заказа
✅ Масштабируемость — фоновые задачи можно обрабатывать в отдельных очередях
✅ Простота реализации — событие «Заказ создан» запускает асинхронные процессы
Почему другие варианты — ошибка:
❌ B — клиент будет ждать все 30 секунд отправки пуша
❌ C — риск потерять заказ, если пуш отправлен, а создание заказа упало
❌ D — избыточная сложность, блокировки, проблемы с производительностью
Ключевой вывод для аналитика: Разделяйте операции на критические для пользователя (требующие немедленного ответа) и фоновые (которые можно выполнить асинхронно). Всегда проектируйте интеграции с учетом реальной производительности внешних систем .
Почему B — правильно:
✅ Скорость ответа клиенту — главное требование выполнено
✅ Устойчивость к сбоям — падение сервиса пушек не сорвет оформление заказа
✅ Масштабируемость — фоновые задачи можно обрабатывать в отдельных очередях
✅ Простота реализации — событие «Заказ создан» запускает асинхронные процессы
Почему другие варианты — ошибка:
❌ B — клиент будет ждать все 30 секунд отправки пуша
❌ C — риск потерять заказ, если пуш отправлен, а создание заказа упало
❌ D — избыточная сложность, блокировки, проблемы с производительностью
Ключевой вывод для аналитика: Разделяйте операции на критические для пользователя (требующие немедленного ответа) и фоновые (которые можно выполнить асинхронно). Всегда проектируйте интеграции с учетом реальной производительности внешних систем
🤔2
4685. Вы проектируете функционал "Черный список" для маркетплейса. Нужно хранить связи "продавец → заблокированный покупатель" и быстро проверять, заблокирован ли конкретный покупатель у конкретного продавца. Какой тип первичного ключа будет оптимальным?
Anonymous Quiz
13%
UUID
6%
BIGINT AUTO_INCREMENT
72%
Составной ключ из ID продавца и ID покупателя (seller_id, buyer_id)
10%
SHA256 хэш от конкатенации ID продавца и покупателя
👩🏫Объяснение:
Данный кейс требует решения двух задач:
1️⃣ Гарантировать уникальность комбинации "продавец-покупатель" (один покупатель не может быть дважды в черном списке у того же продавца).
2️⃣ Обеспечить максимально быструю проверку наличия конкретной пары.
✅ Составной первичный ключ (seller_id, buyer_id) решает обе задачи идеально:
Уникальность обеспечивается на уровне СУБД автоматически.
Скорость поиска: Запрос SELECT 1 FROM blacklist WHERE seller_id = X AND buyer_id = Y будет выполняться по первичному ключу (кластеризованному индексу), что является самой быстрой операцией.
Эффективное использование: Ключ соответствует самому частому сценарию использования — проверка по конкретной паре.
❌ Почему другие варианты хуже:
A (UUID): Случайные значения приводят к сильной фрагментации индексов и неэффективному использованию кэша. Запрос все равно потребует отдельного UNIQUE-ограничения на пару ID.
B (AUTO_INCREMENT): Не гарантирует уникальность логической пары без дополнительного UNIQUE-ограничения. Также при горизонтальном масштабировании (шардинге) могут возникнуть сложности.
D (SHA256): Избыточная вычислительная нагрузка при вставке, те же проблемы с фрагментацией, что и у UUID.
Архитектурный бонус: При таком дизайне легко добавить шардинг по seller_id, если количество продавцов будет огромным. Данные одного продавца будут физически сгруппированы, что улучшит производительность.
1️⃣ Гарантировать уникальность комбинации "продавец-покупатель" (один покупатель не может быть дважды в черном списке у того же продавца).
2️⃣ Обеспечить максимально быструю проверку наличия конкретной пары.
✅ Составной первичный ключ (seller_id, buyer_id) решает обе задачи идеально:
Уникальность обеспечивается на уровне СУБД автоматически.
Скорость поиска: Запрос SELECT 1 FROM blacklist WHERE seller_id = X AND buyer_id = Y будет выполняться по первичному ключу (кластеризованному индексу), что является самой быстрой операцией.
Эффективное использование: Ключ соответствует самому частому сценарию использования — проверка по конкретной паре.
❌ Почему другие варианты хуже:
A (UUID): Случайные значения приводят к сильной фрагментации индексов и неэффективному использованию кэша. Запрос все равно потребует отдельного UNIQUE-ограничения на пару ID.
B (AUTO_INCREMENT): Не гарантирует уникальность логической пары без дополнительного UNIQUE-ограничения. Также при горизонтальном масштабировании (шардинге) могут возникнуть сложности.
D (SHA256): Избыточная вычислительная нагрузка при вставке, те же проблемы с фрагментацией, что и у UUID.
Архитектурный бонус: При таком дизайне легко добавить шардинг по seller_id, если количество продавцов будет огромным. Данные одного продавца будут физически сгруппированы, что улучшит производительность.
4686. При проектировании интеграции CRM и ERP-системы возник спор. Нужно передавать обновлённые данные о клиентах. Какой способ синхронизации оптимален?
Anonymous Quiz
11%
Прямые синхронные API-вызовы при каждом изменении в CRM
72%
Асинхронная передача событий через шину (message broker) с гарантией доставки
6%
Ежечасный batch-экспорт всех данных из CRM и полная перезапись в ERP
12%
Общая база данных, доступная обоим системам
✅ Вариант B решает задачу оптимально:
1. Актуальность в пределах задержки: События обрабатываются почти в реальном времени, укладываясь в 15 минут.
2. Консистентность и надёжность: Шина (Kafka, RabbitMQ) гарантирует доставку каждого сообщения. При сбое ERP данные не теряются, а накапливаются в очереди.
3. Слабая связанность и масштабируемость: Системы не зависят друг от друга напрямую. Можно добавить новых потребителей событий (например, систему аналитики) без изменения CRM.
❌ Почему другие варианты не подходят:
· A (Синхронные вызовы): Создаст хрупкую связь. При недоступности ERP пользователи CRM получат ошибки, а бизнес-процессы встанут. 1000 вызовов в час — значительная нагрузка.
· C (Batch-перезапись): Нарушает требование к актуальности (данные могут устаревать на час). Полная перезапись создает избыточную нагрузку и риск конфликтов при одновременном обновлении.
· D (Общая БД): Антипаттерн интеграции. Нарушает инкапсуляцию систем, создает монолит, усложняет развитие и масштабирование.
💡 Ключевой вывод для аналитика:
При выборе паттерна интеграции оценивайте критичность консистентности vs. допустимую задержку. Асинхронная шина с гарантированной доставкой — золотая середина для сценариев, где допустима небольшая задержка, но недопустима потеря данных или прямая зависимость систем.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
Кажется, знакомая история, не правда ли? Бесконечный поиск "волшебной таблетки" в мире онлайн-маркетинга может вымотать кого угодно. Обещания золотых гор, гуру, предлагающие секретные формулы успеха, и горы потраченных впустую денег.
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/pHXCJW4ugwkyYzQ6
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/pHXCJW4ugwkyYzQ6
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/pHXCJW4ugwkyYzQ6
Результат:
😃за 3 дня работы, +60 подписчиков и 3 продажи сразу.
Попасть в подборку🫶
Чувствуете себя белкой в колесе, которая крутится, но не двигается с места?
🔥ПРИВЛЕКАЙ ПОДПИСЧИКОВ И ПОЛУЧАЙ ЕЖЕДНЕВНЫЕ ЗАЯВКИ БЕСПЛАТНО, С ПОМОЩЬЮ ЭТОГО МЕТОДАРезультат:
😃за 3 дня работы, +60 подписчиков и 3 продажи сразу.
Попасть в подборку
Please open Telegram to view this post
VIEW IN TELEGRAM
4687. Мобильное приложение запрашивает доступ к контактам для реферальной программы. Какое требование по безопасности должно быть в ТЗ в первую очередь?
Anonymous Quiz
13%
Шифрование локальной БД
15%
Двухфакторная аутентификация
67%
Явное согласие пользователя с объяснением цели
4%
Логирование всех операций
✅ Вариант C — ключевое требование на этапе проектирования:
Соответствие GDPR/152-ФЗ: Явное согласие — базовое требование для обработки персональных данных третьих лиц (контактов пользователя).
Transparency by design: Пользователь должен понимать, зачем приложению доступ к контактам и как они будут использоваться.
Доверие пользователей: Четкое объяснение повышает вероятность согласия и снижает риск жалоб.
⚠️ Почему другие варианты — вторичны:
A (Шифрование БД): Важно, но не решает проблему легитимности сбора данных.
B (2FA): Касается аутентификации, а не работы с персональными данными.
D (Логирование): Нужно для аудита, но не для первичного соответствия законодательству.
Профессиональный контекст: Системный аналитик должен начинать проектирование с нормативных требований, особенно в регулируемых отраслях (финансы, здравоохранение). Технические меры безопасности проектируются после определения правовых оснований обработки данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
4688. В системе электронной коммерции нужно хранить заказы. Требования:
Полный аудит всех изменений статусов и данных заказа
Высокая скорость обработки текущих заказов Удобная аналитика данных Какой подход к проектированию хранения данных выбрать?
Полный аудит всех изменений статусов и данных заказа
Высокая скорость обработки текущих заказов Удобная аналитика данных Какой подход к проектированию хранения данных выбрать?
Anonymous Quiz
15%
Одна таблица с флагом актуальности + триггеры для истории
32%
Раздельные таблицы для текущих и архивных заказов
44%
Event Sourcing — хранить ленту событий изменений
9%
Одна таблица + вынос истории в файловые логи
Гарантированный аудит всех изменений
Производительность: актуальное состояние можно быстро восстановить или кэшировать
Гибкую аналитику: можно строить отчёты по любому срезу событий
❌ Другие варианты имеют недостатки:
A: Триггеры скрывают логику, флаги усложняют запросы
B: Риск рассинхронизации, дублирование схемы
D: Файловые логи не позволяют делать сложные SQL-запросы
Вывод для аналитика: Event Sourcing — это не просто техника хранения, а бизнес-требование к отслеживаемости процессов. Подходит для финансовых операций, заказов, документооборота — где важна история изменений.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
4689. Вы проектируете высоконагруженный стриминговый сервис.
Какую архитектурную парадигму выбрать для ядра системы обработки видео-потоков и метаданных?
Какую архитектурную парадигму выбрать для ядра системы обработки видео-потоков и метаданных?
Anonymous Quiz
1%
Классический трехзвенный монолит с общей базой данных
62%
Микросервисная архитектура с выделенными сервисами для видео, рекомендаций, пользователей
30%
Event-Driven архитектура с шиной событий для асинхронной обработки всех действий
7%
Serverless-архитектура на основе функций (FaaS) для каждого endpoint
Независимое масштабирование: Сервис видео-трансляции можно масштабировать отдельно от сервиса рекомендаций, что критично при миллионах просмотров.
Гибкость технологий: Для обработки видео можно использовать C++/Go, для рекомендаций — Python с ML, для пользователей — Java.
Отказоустойчивость: Падение сервиса комментариев не остановит просмотр видео.
Независимые циклы разработки: Команды могут работать параллельно над разными сервисами.
❌ Почему другие варианты не подходят:
A (Монолит): Не способен горизонтально масштабироваться под пиковые нагрузки. Общая БД станет узким местом.
C (Event-Driven): Хороша для реактивных систем, но недостаточна как основная парадигма для стриминга — требует синхронных API для базовых функций.
D (Serverless): Не подходит для долгих видео-сессий из-за ограничений времени выполнения функций и потенциально высоких затрат при непрерывной нагрузке.
💡 Архитектурный компромисс:
В реальности стриминговые платформы используют гибрид: микросервисы для основного функционала + Event-Driven для аналитики и уведомлений + специализированные решения (CDN) для доставки видео.
Ключевой вывод: Выбор архитектуры определяется типом нагрузки и требованиями к масштабированию. Для разнородных нагрузок (тяжелое видео + легкие метаданные) микросервисы дают максимальную гибкость.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1💯1