4840. Распределённая система должна одновременно обеспечивать строгую согласованность данных (consistency) и доступность при любых сбоях. При сетевом разделении система перестаёт принимать записи. Какую теорему иллюстрирует этот пример?
Anonymous Quiz
4%
Теорема Геделя о неполноте
95%
CAP-теорема: из трёх свойств можно гарантировать только два
0%
Закон Амдала
2%
Теорема Коуза
В 2000 году Эрик Брюер сформулировал, что в распределённой системе невозможно одновременно гарантировать три свойства:
Consistency (C) – все узлы видят одни и те же данные в один момент времени (нет устаревших копий).
Availability (A) – каждый запрос получает ответ (даже если некоторые узлы недоступны).
Partition tolerance (P) – система продолжает работать при разрыве связи между узлами (сетевом разделении).
При возникновении сетевого разделения система вынуждена выбирать между C и A:
CP‑система (например, HBase, MongoDB с настройкой по умолчанию) жертвует доступностью: при разделении блокирует запись, чтобы не нарушить согласованность.
AP‑система (например, Cassandra, CouchDB) жертвует строгой согласованностью: возвращает данные, которые могут быть устаревшими, но система остаётся доступной.
Почему это важно для аналитика?
При выборе базы данных для распределённой системы (например, банковской или социальной сети) вы должны понимать, что невозможно получить и строгую согласованность, и абсолютную доступность при любых сбоях.
Финансовые транзакции – приоритет согласованности (CP). Даже если система временно недоступна, деньги не должны потеряться.
Лента новостей – приоритет доступности (AP). Лучше показать слегка устаревшие новости, чем вообще не открыть приложение.
Реальный кейс:
В Amazon при оформлении заказа применяется строгая согласованность (CP), а при просмотре каталога — eventual consistency (AP). CAP-теорема помогает объяснить такие архитектурные компромиссы заказчику.
Вывод:
Аналитик, знающий CAP-теорему, может аргументированно выбирать хранилище данных под бизнес-требования, понимая неизбежные компромиссы.
Please open Telegram to view this post
VIEW IN TELEGRAM
Если коротко, то ИИ уже не будущее, а наше настоящее.
* Он пишет тексты, анализирует данные, автоматизирует продажи, создает изображения и экономит десятки часов в неделю.
Вопрос уже не в том, заменит ли ИИ людей.
Вопрос – кто быстрее научится им пользоваться.
Специально для тебя ПОДБОРКА сильных экспертов в сфере ИИ
Включайся сейчас - 1 клик, без смс и регистрации. 🏁 Не отставай. Или обгоняй.
Делимся знаниями и аудиторией — растём вместе ⚡️
Забирай ПАПКУ бесплатно. Ссылка действительна 24 часа
* Отписаться можно в любой момент. Остаться — тоже. ✔️
Ссылка ➡️ https://t.me/addlist/n__Pk89IyogzOTVk
* Он пишет тексты, анализирует данные, автоматизирует продажи, создает изображения и экономит десятки часов в неделю.
Вопрос уже не в том, заменит ли ИИ людей.
Вопрос – кто быстрее научится им пользоваться.
Специально для тебя ПОДБОРКА сильных экспертов в сфере ИИ
Включайся сейчас - 1 клик, без смс и регистрации. 🏁 Не отставай. Или обгоняй.
Делимся знаниями и аудиторией — растём вместе ⚡️
Забирай ПАПКУ бесплатно. Ссылка действительна 24 часа
* Отписаться можно в любой момент. Остаться — тоже. ✔️
Ссылка ➡️ https://t.me/addlist/n__Pk89IyogzOTVk
🔥1
4841. В системе бронирования билетов критично не потерять ни одной записи. Репликация базы данных настроена асинхронно. При сбое мастер-сервера последних транзакций пропадают. Как изменить настройку репликации, чтобы гарантировать нулевую потерю данных?
Anonymous Quiz
3%
Увеличить количество реплик
88%
Переключиться на синхронную репликацию (операция подтверждается только после записи на реплику)
1%
Увеличить частоту снэпшотов
8%
Включить кэширование на мастере
НЕБОЛЬШОЙ АПГРЕЙД ТВОЕЙ ЛЕНТЫ, КОТОРЫЙ ДАСТ ХОРОШИЙ БУСТ ТВОЕЙ КАРЬЕРЕ
Друзья, наш канал попал в подборку тг-каналов про ИТ, ИИ, технологии и карьеру — получилась такая ламповая тусовка «для своих» 😎
Тут мы собрали каналы для себя, которые реально помогают:
➕ следить за ИИ — от свежих инструментов до реальных кейсов
➕ разбираться в технологиях — тренды, обзоры и объяснения
➕ расти в IT — советы по карьере, поиску работы и развитию
➕ быть в теме HR Tech — как технологии меняют найм и управление
🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/n__Pk89IyogzOTVk
Друзья, наш канал попал в подборку тг-каналов про ИТ, ИИ, технологии и карьеру — получилась такая ламповая тусовка «для своих» 😎
Тут мы собрали каналы для себя, которые реально помогают:
➕ следить за ИИ — от свежих инструментов до реальных кейсов
➕ разбираться в технологиях — тренды, обзоры и объяснения
➕ расти в IT — советы по карьере, поиску работы и развитию
➕ быть в теме HR Tech — как технологии меняют найм и управление
🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/n__Pk89IyogzOTVk
❤1👍1🔥1
Мастер-сервер принимает транзакцию, подтверждает клиенту «успех» и потом отправляет изменения на реплику. Если мастер падает между подтверждением и отправкой, реплика не получает данные → потеря транзакций. Это допустимо в системах, где допустима микро-потеря (например, аналитика), но не в финансовых или критичных системах.
Синхронная репликация
Мастер отправляет данные на реплику, ждёт её подтверждения, и только после этого отвечает клиенту «успех». При падении мастера реплика уже имеет данные, и потери нет. Недостаток: задержка увеличивается, так как клиент ждёт ответа от реплики.
Пример из реальной жизни
В банковских системах (например, при переводе денег) используется синхронная репликация. В социальных сетях (лайки, просмотры) — асинхронная, так как пара потерянных лайков не критична.
Что должен зафиксировать аналитик
Допустимо ли RPO (Recovery Point Objective) больше нуля? Если нет — синхронная репликация.
Какая задержка допустима? Синхронная репликация медленнее.
Нужно ли распределение по географическим зонам? Тогда синхронная репликация может быть очень медленной.
Вывод: Для критичных к потере данных систем синхронная репликация обязательна. Аналитик должен указать это в требованиях к отказоустойчивости.
Please open Telegram to view this post
VIEW IN TELEGRAM
4842. Внешний API ограничивает 10 запросов в секунду. Ваше приложение шлёт 50 запросов в секунду и получает ошибки 429. Какая техника защиты должна быть реализована на стороне клиента?
Anonymous Quiz
9%
Увеличить таймаут соединения
84%
Внедрить token bucket или leaky bucket на клиенте, ограничивая исходящий поток
6%
Увеличить количество потоков
2%
Перестать использовать API
Это алгоритм, который контролирует скорость отправки запросов:
Корзина с токенами (например, 10 токенов).
Каждый запрос забирает 1 токен.
Корзина пополняется с заданной скоростью (например, 1 токен в 0.1 секунды).
Если токенов нет, запрос задерживается или отклоняется.
Leaky bucket — аналогичен, но ограничивает не пиковую скорость, а среднюю.
Почему это должен делать клиент?
Если клиент превышает лимиты API, он получит HTTP 429 («Too Many Requests») и может быть заблокирован. Клиент сам должен ограничивать свою нагрузку, чтобы не перегружать внешний сервис и не терять запросы.
Реальный пример
Twitter API ограничивает 300 запросов на 15 минут. Клиентские библиотеки (например, Tweepy) содержат встроенный token bucket. Без него приложение поймает 429 и упадёт.
Что должен зафиксировать аналитик
Требование: «На стороне клиента реализовать ограничение частоты запросов в соответствии со спецификацией API (token bucket)».
Параметры: максимальная скорость, размер корзины, стратегия при переполнении (блокировка, очередь).
Обработка ошибок 429: увеличение задержки (exponential backoff).
Вывод: Rate limiting — обязанность не только провайдера API, но и клиента. Аналитик должен включать это требование в спецификации интеграций.
Please open Telegram to view this post
VIEW IN TELEGRAM
4843. Заказчик: «Система должна импортировать Excel-файл». Аналитик передал задачу разработчику. Импорт сломался из-за файла в 2 ГБ. Что аналитик упустил?
Anonymous Quiz
1%
Проверку формата файла
97%
Брейкдаун на нефункциональные требования: максимальный размер, скорость, формат, обработка ошибок
1%
Согласование с администратором
1%
Проверку антивирусом
❤2
Максимальный размер файла: 1 МБ или 2 ГБ? Это влияет на потоковую обработку (chunked) vs загрузка в память.
Форматы:
.xlsx.xls.csvСкорость: импорт за 5 секунд или 5 минут?
Обработка ошибок: при неверной строке — откат всего импорта или пропуск с логом?
Многопоточность: можно ли обрабатывать несколько файлов параллельно?
Реальный кейс: Один аналитик не спросил про размер, разработчик загружал файл целиком в память. При 500 МБ сервер упал с OOM. Переделали на потоковый импорт.
Вывод: Любое общее требование должно быть разбито на проверяемые компоненты. Это ключевая техника системного анализа.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
4844. Внешний сервис может присылать уведомления о событиях не мгновенно, а с задержкой до 5 минут. Какой способ получения событий обеспечит минимальную задержку?
Anonymous Quiz
5%
Polling каждую секунду
71%
Webhook (callback)
24%
Очередь сообщений с периодическим чтением
0%
Email-уведомления
Реальный пример: Платёжные системы (Stripe, PayPal) используют webhook для оповещения о статусе платежа. Ваш сервер получает уведомление через секунды после оплаты, а не через минуты при polling.
Вывод: Если внешний сервис поддерживает webhook, это лучший вариант для получения событий в реальном времени. Аналитик должен уметь сравнивать webhook и polling в требованиях к интеграции.
Please open Telegram to view this post
VIEW IN TELEGRAM
В мае стало очевидно: digital снова штормит. AI-выдача давит классический трафик, воронки проседают, и выигрывают не самые опытные — а самые быстрые.
В такой момент решает не количество информации, а её качество.
Мы собрали папку тех, кто уже адаптируется, работает с цифрами и делится тем, что реально даёт результат.
Без шума. Только практика.
Если ты в маркетинге / digital / IT — это способ не выпасть из рынка.
Сохранить папку себе 📨
В такой момент решает не количество информации, а её качество.
Мы собрали папку тех, кто уже адаптируется, работает с цифрами и делится тем, что реально даёт результат.
Без шума. Только практика.
Если ты в маркетинге / digital / IT — это способ не выпасть из рынка.
Сохранить папку себе 📨
4845. Проектируется каталог товаров, где у каждого товара разный набор атрибутов (телефоны: экран, память; книги: автор, издательство). Схема часто меняется. Какой тип БД предпочтителен?
Anonymous Quiz
24%
Реляционная с EAV (сущность-атрибут-значение)
62%
Документоориентированная NoSQL (MongoDB, Couchbase)
1%
Графовая БД
13%
Ключ-значение
Реальный пример: Интернет-магазины электроники используют MongoDB для каталога, чтобы легко добавлять новые характеристики (например, «наличие eSIM») без изменения схемы.
Вывод: Аналитик должен различать случаи: когда схема стабильна и известна — подходит SQL, когда схема часто меняется или вариативна — NoSQL.
Please open Telegram to view this post
VIEW IN TELEGRAM