🔌 WebSockets vs SSE — что выбрать для real-time приложений

Когда нужно передавать данные в реальном времени (чаты, нотификации, трекинг заказов) — выбор часто падает на WebSockets или Server-Sent Events (SSE). Но они решают задачу по-разному 👇

WebSockets

• Двусторонняя связь — клиент и сервер могут отправлять данные друг другу.
• Подходит для интерактивных систем (чаты, онлайн-игры, торговые площадки).
• Работает поверх TCP и требует чуть больше ресурсов (поддерживает постоянное соединение).

SSE (Server-Sent Events)

• Односторонний канал: сервер → клиент.
• Идеален для нотификаций, обновлений данных, live-фидов.
• Использует обычный HTTP, проще масштабируется и поддерживается почти везде.

💡 Главное различие:

WebSocket = “двусторонний диалог”
SSE = “трансляция данных в одну сторону”

🔥 Когда выбирать:

• Реактивные чаты, игры → WebSockets
• Поток уведомлений или обновлений → SSE

🧠 Вышел отличный курс "Тест Middle: Python, PostgreSQL, Redis, GIT" для проверки своего грейда.

Отлично подходит для тех, кто готовится к собеседованию.

⚡️ Свыше 130 вопросов, которые охватывают продвинутые знания по Python, PostgreSQL, Redis и GIT

https://stepik.org/a/254865
https://stepik.org/a/254865
https://stepik.org/a/254865

За промокодом на скидку 20%
пишите сюда 👉 @viviv891

📦 Distributed Locks — как синхронизировать процессы в разных узлах?

Когда у тебя несколько инстансов сервиса (например, в Kubernetes или Docker swarm), и каждый может одновременно попытаться изменить одни и те же данные — начинается хаос 🌀

Чтобы этого не произошло, используют распределённые блокировки (Distributed Locks).

🧠 Зачем нужны?
Чтобы гарантировать, что только один процесс выполняет критическую операцию в один момент времени.

🔧 Реализации:

Redis (Redlock) — популярный вариант от автора Redis.
Работает через SET resource_name my_random_value NX PX 30000.
Если удалось поставить — ты владелец.

Etcd / Zookeeper — используют механизмы watch и lease.

PostgreSQL advisory locks — база может быть тоже “lock-сервером”.

⚠️ Главная сложность:
— Нужно учитывать задержки сети и “split brain” — когда сеть рвётся, и два узла думают, что они владеют замком 😬

✅ Решение:
Алгоритм Redlock — требует 3–5 независимых Redis-нод.
Lock считается валидным, если получил большинство подтверждений (quorum).

Что такое распределённый монолит?

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

👍 - Знал
⚡️ - Не знал

#собес

📣 В чём смысл eventual consistency (финальной согласованности) для распределённых систем?

Ответ:
Eventual consistency — это подход, когда данные в разных частях системы могут отличаться “здесь и сейчас”,
но со временем все узлы приходят к единому состоянию.
Это позволяет строить высоконагруженные и устойчивые к сбоям системы, жертвуя “мгновенной точностью” ради скорости и доступности.

👍 - Знал
🔥 - Не знал

#собес

📦 Обработка файлов: безопасный аплоад, хранение и потоковая передача

При работе с файлами на бэкенде важно не только принимать и сохранять их, но и делать это безопасно и эффективно:

• 🔒 Безопасный аплоад — проверяй MIME-типы, расширения и размер, чтобы не дать пользователю загрузить исполняемый код.

• 💾 Хранение — крупные файлы лучше сохранять вне БД (например, в S3, MinIO или локальном хранилище).

• 🚀 Потоковая передача (streaming) — не загружай файл полностью в память, особенно если он большой. Используй StreamingResponse (FastAPI) или send_file с генератором.

💬 Message Deduplication в Kafka / RabbitMQ — как бороться с дублирующимися сообщениями

В распределённых системах дубликаты сообщений — это норма, а не баг. Сеть может «повторить» запрос, брокер — переотправить сообщение, продюсер — не получить подтверждение и снова отправить.
Если не обработать дубли — бизнес-логика может «стрельнуть себе в ногу».

🧠 Основные подходы к deduplication:

1️⃣ Идемпотентные операции — самое надёжное.
Каждое сообщение обрабатывается так, что повтор не влияет на результат (пример: UPDATE balance SET amount = 100 вместо amount += 100).

2️⃣ Message ID tracking
Храним идентификаторы уже обработанных сообщений (например, в Redis или в compacted-топике Kafka). Если ID уже есть — пропускаем.

3️⃣ Exactly-once delivery (Kafka Streams)
Kafka поддерживает режим exactly-once semantics — гарантирует, что сообщение будет обработано ровно один раз, даже при сбоях.

4️⃣ TTL + Garbage Collector
Старые ID через время можно очищать, чтобы не накапливались в памяти.

⚡️ Главное — помнить:
в очередях не бывает «ровно один раз», бывает “at least once” или “at most once”.
Deduplication — это то, что делает систему надёжной, несмотря на реальность сети.

🔔Сервис нотификации

Сервис нотификации — это компонент микросервисной архитектуры, предназначенный для отправки уведомлений пользователям или другим системам. Он управляет процессом доставки сообщений через различные каналы, такие как электронная почта, SMS, push-уведомления и т.д.

Взаимодействие:
1⃣ Микросервисы: Работает в тесном сотрудничестве с другими микросервисами, такими как сервисы аутентификации (для отправки подтверждений) и заказов (для уведомлений о статусе выполнения).

2⃣ Базы данных: Хранит информацию о пользователях и их предпочтениях по каналам коммуникации.

3⃣ Внешние API: Может интегрироваться с внешними сервисами для отправки SMS или электронной почты.

Используются в:

- Интернет-магазинах: Уведомления о статусе заказа, акциях и скидках.

- Социальных сетях:
Уведомления о новых сообщениях, запросах и обновлениях.

- Финансовых системах: Уведомления о транзакциях, изменениях в счетах и безопасности.

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

💡 Ты случайно объявил два маршрута с одинаковым путем и методом: