15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Шпаргалка по структуре Kubernetes API
👉 @BackendPortal
Идемпотентность это не только проблема консумеров. Kafka уже решает половину задачи на стороне продюсера.
Продюсер помечает каждое событие Producer ID и номером последовательности, которые записываются в лог. Если продюсер делает ретрай из-за ошибки, брокер видит тот же Producer ID + sequence number и отклоняет дубликат. Клиент получает ответ DUP, и в результате не возникает повторных публикаций.
Чтобы это работало, нужно включить enable.idempotence=true, выставить acks=all, оставить количество retries большим (дефолт подходит) и держать max.in.flight.requests.per.connection не больше 5, что по умолчанию уже безопасно с современными брокерами.
Важно помнить, что идемпотентность продюсера не решает проблемы внешних сайд-эффектов вроде записи в базу, HTTP-запросов или отправки писем. Она также не защищает от дубликатов, которые приходят от разных продюсеров, и не устраняет повторы при повторной обработке сообщений консумером, если сайд-эффекты выполняются повторно.
Поэтому общий подход такой: включайте идемпотентность у продюсера, используйте транзакции для построения exactly-once пайплайнов и обрабатывайте дедупликацию сайд-эффектов на стороне консумера.
Можно представить это на примере авиасистемы. Продюсер это система, которая выдает уникальный посадочный талон, состоящий из Producer ID и номера последовательности. Брокер это агент на гейте, который сканирует талон и отклоняет его, если он уже был использован. Консумер это стюардесса, которая проверяет, чтобы пассажир занял только одно место и не создал лишних сайд-эффектов.
Идемпотентность легко написать, но сложно правильно реализовать.
👉 @BackendPortal
Понимание HTTP/1.1 и HTTP/2 помогает лучше разбирать такие пояснения в MDN.
Server-Sent Events — это по сути запрос с очень длинным ответом, в котором постепенно приходят «события».
В случае HTTP/1.1 это значит, что соединение будет занято. А браузеры в h1 ограничивают количество соединений до 6 на домен.
Из-за этого SSE работает плохо в h1 после шести подключений.
В HTTP/2 всё нормально, потому что каждый запрос идёт как отдельный стрим, пока не достигнут лимит max concurrent stream (по умолчанию 128).
В h1 же все следующие SSE-запросы или даже обычные GET-запросы к тому же домену будут ставиться в очередь.
👉 @BackendPortal
Что такое паттерн Builder?
Builder позволяет создавать сложные объекты шаг за шагом, без необходимости конструкторов с кучей параметров.
Паттерн даёт возможность получать разные типы и представления объекта, используя один и тот же процесс построения.
Он относится к группе Creational (порождающих) паттернов, которые фокусируются на создании объектов или связанных между собой групп объектов.
Когда стоит его применять
Используй Builder, когда у объекта много опциональных параметров или нужно создавать разные представления одного и того же продукта.
Идеален для объектов со сложной инициализацией, например, для fluent API или объектов конфигурации.
Пример
var request = new HttpRequestMessageBuilder()
.WithMethod(HttpMethod.Post)
.WithUrl("https://api.example.com/data")
.WithHeader("Authorization", "Bearer token")
.WithJsonBody(new { id = 123 })
.Build();
Director, который определяет порядок шагов, а билдеры предоставляют реализацию. Так один и тот же процесс сборки можно переиспользовать для разных продуктов.
🔵🗣Вырасти до хардового Middle+ аналитика.
Как? Добавьте к своим скилам навыки в проектировании архитектуры и интеграций веб-сервисов!
Рассмотрите — авторский курс про архитектуру и интеграции
с практикой.
—————
По результатам курса вы:
▫️научитесь выбирать стиль интеграции под вашу задачу;
▫️сможете проектировать с нуля и описывать интеграции в современных стилях (API: REST, SOAP, gRPC и др. + брокеры сообщений);
▫️поймете, как правильно собирать требования и моделировать в UML;
▫️подготовитесь к собеседованию, решив более 100 тестов;
▫️разработаете свой API на Python;
—————
🟢Вы получите большую базу фундаментальных знаний, доступ к урокам и обновлениям остается навсегда 💡
• Всю программу и отзывы смотрите в боте курса.
• Бонусный модуль про проектирование баз данных — нормализация, транзакции, основы DWH, индексы.
• Результат после прохождения курса: 15 рабочих проектов в портфолио.
• Доступ к чату учеников (общение, обмен опытом, помощь внутри сообщества)
🔹🔹 С чего начать?🔹🔹
С открытых бесплатных уроков по архитектуре и интеграциям в чат-боте курса. Переходите.
👇
@studyit_help_bot
Скидка на курс от канала —
1 000₽ по промокоду BACKEND до 30 августа
Интересный кейс с CORS
Бэкенд вернул заголовок allow-origin, но то же самое сделал и load balancer
В итоге браузер получает два одинаковых заголовка с разными значениями и кидает ошибку
header contains multiple values but only one is allowed
Большая шпаргалка по системному дизайну
👉 @BackendPortal
На платформе SourceCraft новые возможности для опенсорс разработчиков
Платформа поддерживает полный цикл разработки: от постановки задачи до деплоя в облаке. Внутри — широкий набор инструментов для автоматизации рутины, например, быстрая навигация по коду, гибкая система CI/CD, встроенный ассистент и интеграция с облаком.
В обновлении расширили систему рейтинга. Теперь оценивать репозитории можно не просто одной звездой, а по трехбалльной шкале. Это поможет авторам получать более детальный фидбек, а пользователям — легче находить качественные проекты.
Также добавили систему ачивок — платформа теперь автоматически отслеживает активность (коммиты, ревью, участие в обсуждениях) и награждает за это.
Последняя часть апдейта — запуск грантовой программы для важных и интересных опенсорс-проектов. Можно получить грант на 600 000 рублей в виде кредитов на облачные технологии Yandex Cloud. При выборе проекта смотрят на активность репозитория, пользу, план развития и, конечно, место в рейтинге на самой платформе.
Factory Method Pattern
Factory Method определяет интерфейс для создания объектов, но делегирует выбор конкретного класса наследникам.
Относится к группе Creational, которая решает задачи инстанцирования объектов или семейств связанных объектов.
🔸 Когда применять
Используй Factory Method, когда заранее неизвестно, с какими конкретными типами объектов будет работать код.
Подходит для фреймворков, где требуется поддержка пользовательских классов, или когда нужно предоставить библиотеку продуктов с единым интерфейсом.
🔸 Как реализовать
1. Создай абстрактный класс-создатель с абстрактным фабричным методом
2. Конкретные создатели переопределяют этот метод и возвращают разные типы продуктов
3. Главная задача создателя — не просто создание объектов, а реализация бизнес-логики, которая зависит от этих продуктов
Паттерн выносит код создания объектов в одно место, упрощая поддержку.
Новые типы продуктов можно добавлять без изменения клиентского кода.
🔸 Почему это работает
- Нет жёсткой связки между создателем и конкретными продуктами
- Single Responsibility Principle — код создания вынесен отдельно
- Open/Closed Principle — новые типы можно добавлять без изменения старого кода
🔸 Минусы
- Усложнение за счёт дополнительных классов-создателей
👉 @BackendPortal
Нашёл неплохую опенсорс тулзу — FossFLOW
Она позволяет строить наглядные 3D-диаграммы для архитектуры софта и инженерных систем. Интерфейс удобный, есть импорт и экспорт в JSON, а все данные сохраняются локально прямо в браузере.
Можно пользоваться прямо онлайн
- демо
А можно поднять у себя
- GitHub
👉 @BackendPortal
Согласны?
Если это real-time → WebSockets
Если это про масштаб → Kafka
Если нужна простота → REST
Если нужен хаос → GraphQL
Если это про AI → Python
Если про инфраструктуру → Go
Если про логи → ElasticSearch
Если нужна низкая задержка → Redis
Если нужна высокая доступность → Postgres
Если это стриминг → Flink
Архитектура Stack Overflow — это не то, что вы думаете
В интервью со Скоттом Хансельманом Роберта Арковерде, руководитель инженерного отдела Stack Overflow, рассказала об архитектуре проекта.
Они обрабатывают более 6000 запросов в секунду, 2 миллиарда просмотров страниц в месяц и рендерят страницу примерно за 12 миллисекунд.
Можно было бы предположить, что у них микросервисное решение в облаке с Kubernetes. Но реальность другая. Их решение работает уже 15 лет и это большой монолит, развёрнутый on-premises.
Это по сути одно приложение на IIS, которое обслуживает 200 сайтов. Оно крутится на девяти веб-серверах и одном SQL Server (плюс один горячий standby).
Используется двухуровневое кеширование: первый уровень — на SQL Server с большой RAM (1.5 ТБ), где 30% обращений к БД обслуживаются из памяти, второй — два сервера Redis (master и реплика).
Дополнительно есть 3 сервера с tag-движком и 3 сервера Elastic Search для 34 миллионов поисковых запросов в день.
Всё это обслуживает команда из 50 инженеров, которые могут выкатывать код в прод за 4 минуты и делают это несколько раз в день.
Полный tech-stack:
C# + ASP.NET MVC
Dapper ORM
StackExchange Redis
MiniProfiler
Jil JSON Deserializer
Exceptional (логирование для SQL)
Sigil — генерация .NET CIL (когда C# недостаточно быстрый)
NetGain — высокопроизводительный WebSocket-сервер
Opserver — дашборд мониторинга с данными от Orion, Bosun или WMI
Bosun — backend-система мониторинга на Go
27 августа встречаемся на DrinkUp от Авито для backend-разработчиков в Нижнем Новгороде. Уже предчувствуем горячие споры… ☄️
В планах в формате дискуссий обсудить:
➡️ как правильно структурировать проекты;
➡️ кому и как проще вкатиться в Go и почему он такой странный;
➡️ как LLM помогает разработчикам.
Остальные темы раскрывать не будем — можете посмотреть их по ссылке! Там же, кстати, и регистрация на ивент.
Как обрабатывать 1K одновременных загрузок/скачиваний файлов
1. Используй Object Storage (а не свой бэкенд)
Проблема
CPU и память сервера приложения забиваются под завязку
Решение
- Использовать S3, GCS, Azure Blob — хранилища, заточенные под высокий I/O
2. Используй Presigned URLs
Проблема
Маршрутизация всех загрузок/скачиваний через бэкенд = медленно и дорого
Решение
- Генерировать presigned URL на бэкенде
- Пусть клиент грузит/скачивает напрямую в/из хранилища
3. Дроби на чанки и загружай параллельно
Проблема
Большие файлы висят или падают по таймауту
Решение
- Делить на чанки по 5–10 МБ
- Грузить параллельно через multipart upload (в S3 есть нативно)
4. Асинхронная пост-обработка
Проблема
Обработка (антивирус, сжатие и т.д.) тормозит всё
Решение
- Принимать файл → сразу отдавать 202
- Обрабатывать в фоне через очередь (SQS, RabbitMQ)
5. Контролируй конкурентность
Проблема
Слишком много одновременных загрузок = I/O умирает
Решение
- Лимитировать число загрузок на пользователя
- Использовать backpressure или очередь на клиенте/в браузере
6. Используй CDN для скачиваний
Проблема
Пики трафика на скачивание нагружают origin
Решение
- Кэшировать файлы на edge через CDN (Cloudflare, Akamai, CloudFront)
- Раздавать пользователю с минимальной задержкой
👉 @BackendPortal
Теория графов в реальном мире
🔸LinkedIn: Люди, которых вы можете знать
Каждый профиль — это узел. Каждая связь — это ребро.
Система проходит по этой сети с помощью обхода графа, чтобы предложить связи второй степени.
Ты здесь не просто просматриваешь — тебя обходят. Обход графа: поиск в ширину / поиск в глубину для поиска связей
🔸Uber: Сопоставление пассажиров и водителей
Пассажиры с одной стороны, водители с другой — получается двудольный граф.
Сопоставление происходит через алгоритмы, решающие задачу максимального паросочетания.
Это не магия — это математика. Алгоритм Венгера для оптимального сопоставления
🔸Google Maps: Самый быстрый маршрут
Каждый перекрёсток — это узел. Каждая дорога — это ребро с весом (время в пути).
Карты используют алгоритм Дейкстры или A* для поиска кратчайшего пути.
Этот «самый быстрый маршрут» считается за миллисекунды. Алгоритм Дейкстры + A* с эвристическим поиском
🔸Instagram: Лента рекомендаций
Пользователи и посты образуют огромный граф.
Встраивания графа превращают этот хаос в математическую модель, чтобы находить паттерны и рекомендовать контент.
То, что кажется «открытием», на самом деле — близость в пространстве графа. Node2Vec, GraphSAGE для встраиваний
🔸Git: История коммитов
Твой репозиторий — это не просто таймлайн. Это направленный ацикличный граф.
Каждый коммит указывает на родителя или родителей, позволяя ветвление, слияния и переписывание истории.
Поэтому Git мощный… и иногда пугающий. Структура направленного ацикличного графа для контроля версий
🔸Netflix: Рекомендательный движок
Пользователи, фильмы и история просмотров образуют многослойный граф.
Коллаборативная фильтрация ищет похожих пользователей и советует контент на основе кластеризации графа.
Твой следующий сериал предсказывается графовыми алгоритмами. Факторизация матриц + кластеризация графа
🔸Facebook: Ранжирование новостной ленты
Посты, пользователи, лайки и репосты формируют социальный граф.
Алгоритмы, похожие на PageRank, определяют, что попадёт в ленту, исходя из соцсвязей и вовлечённости.
Твоя лента формируется на основе мер центральности графа. EdgeRank + анализ социального графа
🔸Amazon: Рекомендации товаров
Товары, клиенты и история покупок образуют двудольный граф.
Алгоритмы случайных блужданий и графовые нейросети ищут «клиентов, которые купили это, также купили…».
Каждое «рекомендуем для вас» — это путь в графе товаров. Случайное блуждание + графовые нейронные сети
👉 @BackendPortal
Наткнулся в интернете на интересную мысль:
Первое правило программирования - не делай хуже, чем есть сейчас.
Есть принцип забора Честертона: если ты видишь забор посреди поля, может показаться, что он лишний, и захочется его убрать. Но если ты не знаешь, зачем он там, ты рискуешь ошибиться и дорого за это заплатить.
В софте этот принцип означает: не стоит менять код, архитектуру или процессы, пока не поймёшь, зачем они сделаны именно так.
Любое изменение, будь то рефакторинг, апдейт или удаление — должно иметь чёткое обоснование - измеримый прирост в производительности, удобстве поддержки или опыте пользователей. Иначе легко внести лишние баги и сломать проект.
Очень просто сделать хуже, даже будучи опытным и с хорошими намерениями. Это не вопрос субъективного мнения, я постоянно вижу «оптимизации», которые работают во вред.
Да, кодовая база может казаться старой и грязной. И да, возможно, её действительно стоит организовать по-другому. Но с той же вероятностью ты можешь ошибаться.
Тут важно смирение. Всегда помни, что ты знаешь меньше, чем думаешь, кем бы ни был. Мы склонны переоценивать своё понимание системы.
Поэтому слушай других, кто помогает держать тебя в тонусе. Учись сомневаться в себе, особенно, когда работаешь с зрелым, хорошо протестированным кодом.
👉 @BackendPortal
Это инфографика про GraphQL.
GraphQL — это язык запросов для API.
Клиент обращается к серверу через GraphQL-запрос.
В GraphQL данные описываются через SDL
Можно получать данные , например:
{
user(id: 1) {
name
email
}
}{
createUser(
name: "John Doe",
email: "john@doe.com"
) {
name
email
}
}
🎓 Курс “MongoDB для разработчиков”
1 сентября стартует обучение, которое поможет вам освоить одну из самых востребованных NoSQL-баз данных для современных приложений.
📌 На курсе вы:
научитесь создавать и администрировать базы и коллекции;
проектировать схемы без антипаттернов;
работать с индексами и агрегацией;
настраивать репликацию, шардинг и обеспечивать масштабируемость;
интегрировать MongoDB в CI/CD, Docker, Kubernetes и Terraform;
внедрять практики безопасности и мониторинга.
💡 Особенность курса — практические задания с рецензированием:
проверка ваших решений и обратная связь от преподавателей;
развитие навыков code review;
командные практики, приближенные к условиям реальной разработки.
🔖 По окончании курса вы получите именной сертификат, подтверждающий ваши навыки работы с MongoDB.
👨💻 Курс подходит backend- и web-разработчикам, аналитикам и всем, кто хочет уверенно перейти от реляционных БД к современным NoSQL-технологиям.
🚀 По промокоду MONGODB действует скидка 25 % в течение 24 часов
📅 Старт обучения: 1 сентября
📍 Формат: онлайн
👉 Записаться на курс
Протоколы в одну строку
HTTP Запрос → Ответ
WebSockets Соединение → Диалог
gRPC Функции → По сети
SOAP Запросы на XML → Жёсткие контракты
GraphQL Гибкие запросы → Индивидуальные ответы
REST Ресурсы → CRUD-операции
WebRTC Peer-to-peer → Реальное время (медиа/данные)
👉 @BackendPortal
Большинство фейлов в Event-Driven архитектуре происходят не из-за Kafka, RabbitMQ или брокера
Главная проблема — плохая дисциплина при проектировании событий
Вот 4 типичных грабли и как их обходить
1. События перегружены лишними данными
События раздуваются, растёт сетевой трафик, консьюмеры вынуждены парсить ненужные поля, а эволюция схемы становится болью
Как исправить? держите событие лёгким, включайте только то, что реально нужно консьюмерам. Событие должно описывать что произошло, а не тащить полный снапшот
2. Нет идемпотентности
Ретраи неизбежны. Без идемпотентности консьюмеры могут дважды списать деньги, задвоить записи или поломать состояние
Как исправить? используйте идемпотентный ключ (ID события, aggregate + версия). Проектируйте консьюмеров так, чтобы повторная обработка того же события не меняла результат
3. Нет обработки Dead-Letter
Проблемные сообщения могут встать колом или потеряться, и вы не увидите ошибок.
Как исправить? всегда настраивайте Dead Letter Queue (DLQ). Отправляйте туда фейловые события после N ретраев, поднимайте алерты и стройте понятный путь для их реплея
4. Нет версионирования
События — это контракты. Если менять их без плана, консьюмеры сломаются
Как исправить? версионируйте события явно (например OrderCreated.v1, OrderCreated.v2). Держите старую и новую версии параллельно, пока все не мигрируют
Если обойти эти 4 грабли, можно избежать 90% проблем, которые обычно ловят команды
На фото чеклист, чтобы не наступать на них
👉 @BackendPortal
Когда обсуждаем интеграции, мы обычно упираемся в одно и то же: бэкенд ещё не готов, фронт ждёт, тесты стопорятся.
Но есть маленький трюк в DevTools, который я выцепил из поста Даниэля Ленца, фронтент-разработчика из Яндекса.
Фронт или QA могут подменять ответы сервера прямо в браузере.
Без моков в коде, без поднятого стаба — просто локальный ответ, который ведёт себя как реальный.
Что это даёт:
- Контракты проверяются быстрее: вы описали структуру, они сразу «прокрутили» её в интерфейсе.
- Реже приходится поднимать временные ручки «чтобы фронту было с чем поиграться».
- Легче разбирать инциденты: QA может воспроизвести нестандартные статусы и заголовки локально.
То есть часть «мелких зависимостей» от бэка снимается, команда двигается быстрее, а вы меньше отвлекаетесь на вспомогательные задачи.
Что ты пишешь:
fetch("/users/123")
Когда понимаешь, что большинство операций копирования памяти выполняются на CPU — твой взгляд на software engineering меняется
Ты начинаешь иначе смотреть на программы видишь узкие места понимаешь мотивацию в pull request’ах от сеньоров и наконец полностью осознаёшь суть топовых докладов вроде этого про async I/O в Postgres
Баги которые раньше казались мистикой становятся очевидными
👉 @BackendPortal
Нашёл на YouTube плейлист по бэкенд-инжинирингу — начинается с HTTP и дальше разбирает роутинг, безопасность, масштабирование и прочее. Всё объяснено просто и понятно, реально полезный материал. Делюсь, может кому зайдёт.
👉 @BackendPortal
Паттерны проектирования систем - шпаргалка
🔸Webhooks и Outbox
Надёжные внешние уведомления.
Когда использовать — интеграции, сторонние колбэки.
Типичные проблемы — статусы оплат, синхронизация CRM.
🔸Blob/Object Storage
Дешёвое хранение больших файлов.
Когда использовать — медиа, бэкапы, экспорты.
Типичные проблемы — загрузки пользователей, data lake.
🔸Оркестратор задач (Airflow/Temporal)
Долгоживущие процессы с состоянием.
Когда использовать — длинные задачи, SLA.
Типичные проблемы — генерация отчётов, обработка видео.
🔸Blue-Green / Canary деплой
Постепенное переключение трафика.
Когда использовать — безопасные релизы, быстрый откат.
Типичные проблемы — деплой API, смена конфигураций.
🔸Feature Flags
Включение/отключение фич на лету.
Когда использовать — эксперименты, переключатели.
Типичные проблемы — A/B тесты, скрытые релизы.
🔸Стратегия миграции схемы
Обратная/прямая совместимость.
Когда использовать — миграция без простоя БД.
Типичные проблемы — expand-migrate-contract.
🔸Распределённые блокировки / выбор лидера
Координация одного активного воркера.
Когда использовать — уникальность cron, шардовое владение.
Типичные проблемы — один консумер, лидер партиции.
🔸Наблюдаемость (логи/метрики/трейсы)
Понимание, что делает система.
Когда использовать — SLO, отладка, планирование.
Типичные проблемы — задержка p99, error budget.
🔸Безопасность: AuthN/AuthZ
Проверка личности и прав доступа.
Когда использовать — мультиарендные продукты, внешние API.
Типичные проблемы — OAuth2/OIDC, RBAC/ABAC.
🔸Мультиарендность (pool/bridge/isolated)
Уровни изоляции данных и ресурсов.
Когда использовать — SaaS с множеством клиентов.
Типичные проблемы — отдельные БД на арендатора vs общая схема.
🔸Edge Compute/функции
Запуск логики ближе к пользователю.
Когда использовать — низкая задержка, лёгкие задачи.
Типичные проблемы — персонализация на краю, A/B тесты.
🔸Rate-Aware DB Patterns
Пакетная, очередная, троттлинг у БД.
Когда использовать — горячие партиции, блокировки.
Типичные проблемы — массовый импорт, ID hotspot.
🔸Стратегии пагинации
Keyset > Offset для больших данных.
Когда использовать — бесконечный скролл, большие таблицы.
Типичные проблемы — пагинация фидов, списки в админке.
👉 @BackendPortal
ChatGPT 5 — страшное оружие в умелых руках
Российский разработчик Олег Миллер, занимающий обучением и тренировкой новой модели Open AI в Сан-Франциско, рассказывает в своём блоге:
• Как отключить цензуру у ChatGPT (инструкция)
• Малоизвестные ИИ, с которыми вы станете богатым
• Почему человечество обречено на катастрофу из-за развития ИИ
За такие инсайды он может быть уволен. Поэтому блог закрытый, а ссылка на него постоянно меняется. Успей вступить: /channel/+l0m6bHg7b94xZGE6
Шпаргалка по основам распределенных систем
🔸Теорема CAP
Нельзя одновременно иметь Consistency, Availability и Partition tolerance
Используется при выборе компромиссов в распределённых БД
Примеры: CP — Zookeeper, AP — Cassandra
🔸Модели согласованности
Strong, Eventual, Causal, Read-your-writes
Применяются при выборе между задержкой и корректностью
Примеры: счётчик лайков vs банковский баланс
🔸Выбор лидера
Выбор одного координатора
Используется для управления кластером и владения партициями
Примеры: ZooKeeper, Raft
🔸Алгоритмы консенсуса
Достижение согласия о значении между нодами
Применяются для обновлений конфигурации и упорядочивания событий
Примеры: Raft, Paxos, Viewstamped Replication
🔸Чтения/записи с кворумом
Требуется подтверждение большинства
Используется для баланса между задержкой и согласованностью
Примеры: базы данных в стиле Dynamo
🔸Партиционирование / шардирование
Разделение данных или работы между нодами
Применяется для масштабирования за пределы одной машины
Примеры: шардирование по user-id, гео-шарды
🔸Репликация (синхронная/асинхронная)
Хранение нескольких копий данных
Используется для высокой доступности и низкой задержки чтения
Примеры: реплики MySQL, Kafka ISR
🔸Протокол Gossip
P2P-распространение состояния
Применяется в больших кластерах и для обнаружения сбоев
Пример: членство нод в Cassandra
🔸Векторные часы
Отслеживание причинного порядка событий
Используется для разрешения конфликтов
Пример: разрешение конфликтов в Dynamo
🔸Метки времени Лампорта
Логический порядок событий
Применяется в распределённом логировании и упорядочивании
Пример: Total order broadcast
🔸Семантика доставки сообщений
At-most-once, At-least-once, Exactly-once
Используется для надёжной обработки событий
Примеры: Kafka consumers, отправка email
🔸Ключи идемпотентности
Предотвращение дублирующих эффектов
Применяются при повторах в ненадёжных сетях
Примеры: обработка платежей, повтор задач
🔸Обработка eventual consistency
Разрешает временное чтение устаревших данных
Используется для низкой задержки и гео-репликации
Примеры: DNS-записи, социальные ленты
🔸Распределённая блокировка
Один активный владелец на всех нодах
Применяется для задач лидера и cron-задач
Примеры: Redis Redlock, ZK locks
👉 @BackendPortal
Это схема-шаблон для проектирования архитектуры сложных распределённых систем
Она показывает, как обычно строятся крупные веб-сервисы с микросервисной архитектурой и распределённой обработкой данных.
👉 @BackendPortal
Хочешь расти в разработке и делать проекты, а не просто "писать код"?
В моём Telegram-канале — честно и по делу:
— Как устроены технологии под капотом
— Как прокачиваться и выходить на уровень выше
— Мой опыт как разработчика и инженера: код, архитектура, фейлы, найм и запуски собственных проектов
Ни воды, ни мотивационных лозунгов — только реальный опыт, который редко встретишь в статьях.
Несколько постов, с которых можно начать:
— 👉Что нужно знать программисту кроме ЯП
— 👉 Как правильно собеседовать джунов
— 👉 Бывший работодатель хотел вернуть деньги
— 👉 Когда проект затянулся на полгода. И сожрал нервы.
— 👉 Делаю свой веб-фреймворк на C# с нуля (4.5 часа видео)
Если тебе близка такая подача — подписывайся. Увидимся там:
👨💻 @ruslan_shishmarev
Liam ERD
Это опенсорсный инструмент, который мгновенно генерирует красивые, интерактивные ER-диаграммы из существующих баз данных
Просто загружаете схему, и получаете понятные визуализации, где можно удобно смотреть связи, приближать, фильтровать и быстро разбираться даже с суперсложными структурами.
И всё это бесплатно и без необходимости регистрации. Инструкция на GitHub, ссылка на сервис.
👉 @BackendPortal