ИИ - УЖЕ НЕ «ПОТОМ». ОН ПРЯМО СЕЙЧАС ПЕРЕПИСЫВАЕТ ПРАВИЛА ...
Тексты, анализ, продажи, дизайн, экономия десятков часов в неделю — это не футурология. Это твой обычный вторник.
Вопрос давно не в том, заменит ли ИИ людей.
Вопрос в том, кто обгонит тебя, пока ты думаешь.
Хочешь быть среди первых, кто использует нейросети в полную силу?
ПОДБОРКА сильных экспертов по Нейросетям и ИИ — забирай, пока другие скролят новости:
Остаться или отписаться сможешь в любой момент ✔️ * Ссылка - https://t.me/addlist/6jvq2ugAARVhNjc0
Тексты, анализ, продажи, дизайн, экономия десятков часов в неделю — это не футурология. Это твой обычный вторник.
Вопрос давно не в том, заменит ли ИИ людей.
Вопрос в том, кто обгонит тебя, пока ты думаешь.
Хочешь быть среди первых, кто использует нейросети в полную силу?
ПОДБОРКА сильных экспертов по Нейросетям и ИИ — забирай, пока другие скролят новости:
Остаться или отписаться сможешь в любой момент ✔️ * Ссылка - https://t.me/addlist/6jvq2ugAARVhNjc0
🔥2👍1
4766. В глобальном чат-приложении сообщения хранятся в таблице messages. Топ-запрос: «показать последние 100 сообщений в диалоге между пользователями A и B». Какой первичный ключ обеспечит лучшую производительность при шардировании?
Anonymous Quiz
21%
(message_id) — глобальный автоинкрементный идентификатор
47%
(user_a_id, user_b_id, created_at)
25%
(dialog_id, created_at)
7%
(created_at, message_id)
При огромном объёме данных (миллиарды сообщений) неизбежно горизонтальное масштабирование (шардирование). Ключевой принцип: данные, которые часто запрашиваются вместе, должны лежать на одном шарде. В чате все сообщения одного диалога запрашиваются вместе (лента переписки). Если эти сообщения разбросаны по разным шардам, каждый запрос «последние 100 сообщений диалога» превратится в сложный distributed join и сборку результатов, что приведёт к высоким задержкам.
2. Почему (dialog_id, created_at) — оптимально?
dialog_id — уникальный идентификатор пары собеседников (например, хеш от min(user_id, peer_id) + max(...)).
Все сообщения одного диалога попадают в один шард (шардирование по dialog_id).
created_at обеспечивает сортировку внутри диалога и уникальность в составе ключа.
Запрос «последние 100 сообщений» читает данные с одного шарда, по одному индексу, в отсортированном порядке — максимально быстро.
3. Почему другие варианты плохи?
A (message_id) — глобальный автоинкремент не подходит для шардирования: сообщения одного диалога попадают в разные шарды (последовательные ID распределяются по серверам). Запрос за 100 сообщениями диалога затронет все шарды, соберёт их, потом отсортирует и обрежет — очень дорого.
B ((user_a_id, user_b_id, created_at)) — семантически близко к dialog_id, но занимает больше места и требует фиксированного порядка двух ID (нужно сортировать, чтобы гарантировать одинаковый ключ для диалога A–B и B–A). dialog_id — это уже свертка, удобнее.
D ((created_at, message_id)) — шардирование по времени размажет один диалог по многим шардам (сообщения за разные даты). Запрос последних сообщений диалога снова соберёт все шарды.
4. Реальный кейс
Telegram, WhatsApp, VK используют похожую схему: ключ = (chat_id, message_id), где message_id возрастает внутри чата.
Шардирование по chat_id. Благодаря этому даже при миллиардах сообщений открыть любой диалог можно за миллисекунды.
Что должен зафиксировать аналитик:
Ключ шардирования = dialog_id.
Кластерный индекс = (dialog_id, created_at).
Для уникальности можно добавить message_id как автоинкремент внутри диалога (но вторичный ключ).
Вывод: Выбор первичного ключа и ключа шардирования — не техническая деталь, а архитектурное решение, влияющее на масштабируемость и пользовательский опыт. Аналитик, понимающий паттерны доступа к данным, помогает проектировать схему БД, которая не сломается под миллиардами записей. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
4767. В системе заказов используется Kafka. Один из консьюмеров обрабатывает события и обновляет базу данных. После перезапуска консьюмера некоторые события были обработаны дважды, что привело к дубликатам в БД. Какое требование к интеграции было упущено?
Anonymous Quiz
2%
Увеличение количества партиций
85%
Идемпотентность обработки сообщений
8%
Синхронный коммит смещений
5%
Настройка retention в топике
Как решается проблема?
Требование идемпотентности на стороне потребителя: обработка одного и того же сообщения несколько раз должна давать тот же результат, что и однократная. Для этого можно:
Хранить уникальный идентификатор сообщения (например, messageId) и проверять его наличие в БД перед обработкой.
Использовать атомарные операции (например, INSERT ... ON CONFLICT DO NOTHING).
Вести отдельную таблицу обработанных ID с TTL.
Пример кода (идемпотентный консьюмер на Python):
```python
import redis
cache = redis.Redis()
def process_message(msg):
msg_id = msg['id']
# Проверяем, не обрабатывали ли уже
if cache.exists(msg_id):
print(f"Дубликат {msg_id}, пропускаем")
return
# Блокируем ID на время жизни (например, 24 часа)
cache.setex(msg_id, 86400, "done")
# Основная бизнес-логика (обновление БД)
update_database(msg)
```
❌ Почему не подходят другие варианты:
A (больше партиций) — увеличивает параллелизм, но не решает дублирование.
C (синхронный коммит) — уменьшает риск потери сообщений, но не устраняет повторную обработку при сбое.
D (retention) — влияет на время хранения сообщений, а не на дублирование.
Реальный кейс:
В платёжном сервисе после перезапуска консьюмера дважды списывались средства с некоторых пользователей. Причина — отсутствие идемпотентности. После внедрения проверки уникальных ID транзакций проблема ушла.
Вывод для аналитика:
В требованиях к интеграции через брокеры сообщений обязательно нужно указывать, что потребители должны быть идемпотентными, если повторная обработка может нанести ущерб (списания, отправка уведомлений, создание заказов). Это требование должно проверяться приёмными тестами. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
4768. При падении потребителя после обработки сообщения, но до отправки подтверждения,
сообщение возвращается в очередь и обрабатывается снова. Какая гарантия доставки обеспечивается в этом сценарии?
сообщение возвращается в очередь и обрабатывается снова. Какая гарантия доставки обеспечивается в этом сценарии?
Anonymous Quiz
17%
Exactly‑once
79%
At‑least‑once
3%
At‑most‑once
1%
No guarantee
В RabbitMQ (и многих других брокерах) используется модель с подтверждениями: потребитель явно отправляет basic.ack после успешной обработки сообщения. Если потребитель упал до того, как отправил ack, брокер считает сообщение недоставленным и снова ставит его в очередь для другого потребителя или при перезапуске.
Что это даёт?
· Сообщение точно не будет потеряно (если брокер сохранил его на диск).
· Но оно может быть обработано более одного раза (например, если после обработки, но до ack случился сбой). Это называется at‑least‑once (как минимум один раз).
Почему не exactly‑once (A)?
Exactly‑once требует идемпотентной обработки и часто дополнительных механизмов (транзакции брокера, idempotent producer). Простой ack даёт только at‑least‑once.
Почему не at‑most‑once (C)?
At‑most‑once означал бы, что сообщение может потеряться. Здесь же брокер будет повторять доставку.
Реальный кейс:
В сервисе уведомлений использовали авто-ack (подтверждение сразу после получения, до обработки). При падении потребителя сообщения терялись — это at‑most‑once. Перешли на ручной ack после обработки — получили at‑least‑once, но иногда были дубликаты писем. Затем добавили идемпотентность на стороне потребителя (проверку по ID сообщения) и достигли exactly‑once.
Что должен знать аналитик:
· Гарантии доставки — это компромисс между надёжностью и производительностью.
· At‑least‑once подходит для большинства бизнес-сценариев, если потребитель идемпотентен.
· Если дубликаты недопустимы (финансы), требуйте exactly‑once или проектируйте идемпотентность.
Вывод: При описании интеграций аналитик должен явно указывать требуемую гарантию доставки и стратегию подтверждений. Это влияет на надёжность системы.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Сейчас в IT ощущается переломная фаза: компании уже не просто «закрывают вакансию аналитика», а ищут людей, которые умеют говорить и на языке бизнеса, и на языке продукта, и на языке разработки, без лишней воды и формализма.
Собрали папку, в которую складываем именно то, что реально помогает вникнуть в бизнес‑анализ и IT‑среду, а не просто «заполнить ленту».
Тут: разборы задач, примеры документов, чек‑листы, ссылки на качественные каналы и инструменты, которые помогают разобраться в профессии и не тонуть в потоке.
Сохранить папку себе 📨
Это хороший знак: рынок перестаёт довольствоваться «человеком‑исполнителем» и всё больше ценит тех, кто понимает, зачем нужен каждый документ, схема и требование, и как всё это связано в одну систему.
Собрали папку, в которую складываем именно то, что реально помогает вникнуть в бизнес‑анализ и IT‑среду, а не просто «заполнить ленту».
Тут: разборы задач, примеры документов, чек‑листы, ссылки на качественные каналы и инструменты, которые помогают разобраться в профессии и не тонуть в потоке.
Сохранить папку себе 📨
4769. Для системы заказов нужны: порядок событий для каждого заказа, 100 000 событий/с, отказоустойчивость. Какой брокер и настройка обеспечат баланс?
Anonymous Quiz
17%
RabbitMQ с классической очередью и несколькими потребителями
76%
Kafka с партиционированием по order_id и acks=all
2%
Redis Pub/Sub с постоянным хранением на диске
5%
ActiveMQ с персистентными очередями
Порядок сообщений: Kafka гарантирует строгий порядок внутри одной партиции. Если отправлять все события одного заказа с одинаковым ключом (order_id), они попадут в одну партицию и будут обрабатываться последовательно. RabbitMQ при нескольких потребителях порядок не гарантирует (даже с одним потребителем — да, но пропускная способность упадёт).
Высокая пропускная способность: Kafka рассчитана на 100 000+ событий/сек благодаря пакетной обработке, последовательной записи на диск и эффективному сжатию. RabbitMQ на таких объемах начинает деградировать (особенно с персистентностью).
Отказоустойчивость: acks=all в Kafka означает, что лидер ждёт подтверждения от всех реплик (in-sync replicas) перед ответом продюсеру. Ни одно сообщение не теряется, если хотя бы одна реплика жива. RabbitMQ с зеркалированием очередей тоже отказоустойчив, но при высоких нагрузках это снижает производительность сильнее, чем в Kafka.
Почему не подходят другие варианты?
A (RabbitMQ) — при нескольких потребителях порядок не гарантируется. Даже с одним потребителем пропускная способность будет ниже 100 000/с, особенно с персистентностью.
C (Redis Pub/Sub) — Pub/Sub не хранит сообщения для отставших потребителей (если потребитель упал — сообщения теряются). Redis Streams может, но уступает Kafka по масштабируемости.
D (ActiveMQ) — устаревший брокер, не рассчитан на такие нагрузки.
Реальный кейс:
Логистическая компания перешла с RabbitMQ на Kafka после того, как при пике 50 000 заказов/час порядок обработки начал нарушаться (сообщения одного заказа уходили разным потребителям). После настройки партиционирования по order_id и acks=all производительность выросла до 200 000/сек, а порядок стал строгим.
Что должен зафиксировать аналитик:
Выбор брокера не на вкус, а под требования: Kafka — для потоков больших объёмов с гарантией порядка и отказоустойчивостью; RabbitMQ — для сложной маршрутизации и малых/средних нагрузок.
В требованиях указать ключ партиционирования (order_id), настройку acks, количество реплик.
Вывод: Выбор брокера сообщений — архитектурное решение, влияющее на масштабируемость и надёжность. Аналитик должен понимать разницу, чтобы закладывать правильные нефункциональные требования.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
⏱️Папка скоро исчезнет. И это не кликбейт.
Если ты маркетолог и до сих пор откладываешь «посмотреть потом» — потом может не наступить.
Здесь не просто файлы.
Здесь то, что экономит часы работы, спасает от выгорания и даёт идеи, за которые обычно платят.
📌 Готовые решения, которые можно брать и внедрять;
📌 Формулировки, которые реально продают;
📌 Подходы, которые выделяют тебя среди остальных.
☝️Но есть нюанс.
Доступ к папке закрывается.
Без громких анонсов, без второго шанса и без «ещё пару дней подержим».
Если ты понимаешь, что тебе это нужно — забирай сейчас👇
https://t.me/addlist/KJwPBSB44eg5NTli
Потом останется только читать чужие результаты.
Если ты маркетолог и до сих пор откладываешь «посмотреть потом» — потом может не наступить.
Здесь не просто файлы.
Здесь то, что экономит часы работы, спасает от выгорания и даёт идеи, за которые обычно платят.
📌 Готовые решения, которые можно брать и внедрять;
📌 Формулировки, которые реально продают;
📌 Подходы, которые выделяют тебя среди остальных.
☝️Но есть нюанс.
Доступ к папке закрывается.
Без громких анонсов, без второго шанса и без «ещё пару дней подержим».
Если ты понимаешь, что тебе это нужно — забирай сейчас👇
https://t.me/addlist/KJwPBSB44eg5NTli
Потом останется только читать чужие результаты.
4770. В API заказа автотест в тесте стабилен, в бое падает при параллельных заказе и бонусе. Какой тип тестирования выявил бы дефект?
Anonymous Quiz
4%
Модульное тестирование
19%
Интеграционное тестирование
77%
Нагрузочное тестирование (или тестирование параллельных запросов)
0%
Тестирование безопасности
Нагрузочное тестирование (или тестирование параллелизма) специально симулирует одновременные запросы нескольких пользователей. Именно оно могло бы воспроизвести проблему на этапе тестирования до релиза.
❌ Почему не другие варианты:
A (модульное) — проверяет отдельные функции изолированно, race condition не поймает.
B (интеграционное) — обычно проверяет взаимодействие компонентов в последовательном режиме.
D (безопасность) — не относится к проблеме.
Реальный кейс: В интернет-магазине при параллельном оформлении заказа и начислении кешбэка иногда списывались лишние бонусы. Причина — отсутствие блокировки строки в БД. Нагрузочный тест с 50 одновременными пользователями выявил бы проблему.
Что должен сделать аналитик:
Включать в план тестирования сценарии параллельных запросов для критичных операций.
Требовать от команды проведения нагрузочных тестов перед релизом.
В требованиях указывать необходимость блокировок (пессимистических или оптимистических) для разделяемых ресурсов.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
4771. После добавления промокода автотесты заказа упали. Баг исправлен, но тесты падают из-за нового поля в API. Какой вид тестирования нужен?
Anonymous Quiz
14%
Модульное тестирование
74%
Тестирование контрактов (Contract testing)
7%
Нагрузочное тестирование
5%
Юзабилити-тестирование
❤1
Разработчик изменил API (добавил новое поле в ответ), но не уведомил команду, которая пишет автотесты на клиентской стороне. Старые тесты ожидали старый формат ответа и упали. Это классический пример ломающего изменения (breaking change) в контракте между сервисами.
Что такое тестирование контрактов?
Это практика, при которой обе стороны (поставщик API и потребитель) договариваются о спецификации (контракте) и автоматически проверяют, что ни одна сторона не нарушает его. Инструменты: Pact, Spring Cloud Contract, Postman с коллекциями.
Как это работает:
Потребитель пишет тест, в котором описывает ожидаемый формат ответа (поля, типы, обязательность).
Поставщик API запускает эти тесты в своём CI и не может выкатить изменение, которое их ломает, без согласования.
Пример контракт-теста на Pact (Python):
```python
from pact import Consumer, Provider
def test_order_contract():
expected = {
"order_id": 123,
"total": 1000,
"delivery_discount": 0 # новое поле
}
# Ожидаем, что API вернёт именно такую структуру
...
```
❌ Почему не другие варианты:
A (модульное) — проверяет функции изолированно, не поймает изменение API.
C (нагрузочное) — проверяет производительность, а не корректность формата.
D (юзабилити) — про удобство интерфейса.
Реальный кейс:
В микросервисной архитектуре компании из 20 сервисов каждый месяц происходило несколько инцидентов из-за несовместимых изменений API. После внедрения контракт-тестов с Pact число таких инцидентов упало до нуля.
Что должен сделать аналитик:
Включить в определение готовности (DoD) требование наличия контракт-тестов для всех публичных API.
Фиксировать в спецификации обязательные и опциональные поля, а также версионирование API.
Требовать, чтобы breaking changes вводились только с новой версией API (v1, v2).
Вывод: Тестирование контрактов — это страховка от неожиданных изменений API, которые ломают интеграции. Аналитик, знающий этот инструмент, помогает команде избежать многих ночных дежурств. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1