15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Видеостриминговый стартап из Сингапура провёл техническое собеседование в необычном формате
Кандидат на позицию Backend и Infra инженера за 4 часа вместе с командой собрал прототип аналитического движка. В работе использовали Go, PostgreSQL и Grafana, а для фронтенда выбрали Claude.
Исходный код проекта открыт: https://github.com/mrinalxdev/go-grafana
👉 @BackendPortal
Задержки это смерть от тысячи мелких порезов.
Так что чините. Начните с базы: один плохой запрос легко добавляет полсекунды, а на тысячах запросов это превращается в катастрофу. Не используйте SELECT *, добавляйте индексы, убивайте N+1 и всегда проверяйте запросы через EXPLAIN.
Дальше посмотрите на сетевые прыжки. Каждый переход через цепочку сервисов добавляет задержку, поэтому мелкие сервисы иногда лучше объединить. Хорошая идея — использовать BFF.
Кэш тоже обязателен. Если данные не меняются, нет смысла тянуть их заново. Сессии, каталоги, конфиги — держите их горячими. Протухший кэш плохо, но отсутствие кэша почти всегда хуже.
Не отправляйте десятки мелких запросов последовательно. Объединяйте их в батчи или гоните параллельно, так результат приходит быстрее.
И не таскайте лишние данные. Убирайте ненужные поля, сжимайте ответы, делайте пагинацию и оптимизируйте картинки.
Скорость это не дополнительная фича, а фундамент нормального UX.
👉 @BackendPortal
Вышел Kubernetes 1.34
Разработчики сообщили о релизе новой версии Kubernetes. Те, кто хочет протестировать обновления прямо сейчас, могут воспользоваться обновлённым playground Kubernetes the Hard Way: ссылка
👉 @BackendPortal
Как один баг в Google Cloud уронил весь Интернет
12 июня Google Cloud упал, и вместе с ним перестали работать Spotify, Fitbit, Gmail, Google Drive, Vertex AI и десятки других сервисов. Причиной оказался всего один null pointer баг в Service Control — сервисе, через который проходит почти каждый запрос к Google Cloud API.
Все запросы проходят через Service Control, он как вышибала, решающий, есть ли у тебя доступ. Если он падает, то рушится всё.
В конце мая Google добавил туда новый код для проверки квот, где не было обработки ошибок на пустые поля. На тестах этот код не активировался, потому что требовалась специфичная политика. Не было ни feature flag, ни постепенного раската — просто мёртвый код, ждавший своего часа.
12 июня утром в базы попала политика с пустыми полями. Service Control попытался её обработать, наткнулся на null pointer и упал.
Spanner почти мгновенно разнёс некорректные данные по всему миру, и каждая инстанция, которая к ним обратилась, падала следом. Двух минут хватило, чтобы Google Cloud лег глобально.
Начались таймауты, 503 от перегруженных систем и 401, когда пустые политики интерпретировались как отсутствие прав.
Пользователи Spotify массово получали 401, Fitbit выдавал разные ошибки в зависимости от региона, сервисы не могли пройти аутентификацию к своим бэкендам.
У Google был kill switch — красная кнопка, чтобы отключить проблемный код. Её нажали через сорок минут, и большая часть регионов восстановилась. Но us-central1 оставался недоступен ещё три часа. Когда тысячи инстансов Service Control перезапустились одновременно, они одновременно пошли в базу и устроили эффект стада, который уронил даже сам фикс.
Хуже всего то, что статус-дэшборд Google тоже крутился на Google Cloud. Когда облако упало, он умер вместе с ним, и мониторинг ослеп. Команды поддержки почти час работали вслепую.
Инцидент случился потому, что не было feature flag на новом коде, не было проверки на null в критическом пути, данные с багом мгновенно разлетелись по всему миру, восстановление не имело задержек и мониторинг был привязан к той же инфраструктуре, которую он должен был отслеживать.
После этого Google заморозил изменения в Service Control, начал переделывать систему так, чтобы компоненты могли падать независимо, добавляет задержки в репликацию, чтобы отлавливать некорректные данные, и строит отдельный мониторинг, который будет жить вне основной системы.
В итоге вся история показала, что один пропущенный if может уронить одну из самых сложных платформ в мире. Не атака и не катастрофа, а просто null pointer.
В распределённых системах локальный сбой превращается в глобальную аварию быстрее, чем человек успевает отреагировать. Инфраструктура, которая даёт масштаб, так же усиливает и ошибки.
Любой запрос к API всегда на расстоянии одного непроверенного значения от фатала. Это и есть реальность современной облачной архитектуры.
Полный отчет о происшествии: ссылка
👉 @BackendPortal
YAML известен тем, что он не друг никому и враг почти каждому. Попробуй это, чтобы понять, друг он тебе или враг.
Тест, с которым можно проверить, насколько хорошо ты знаешь YAML-файлы, а насколько нет :)
👉 @BackendPortal
Интересный кейс поведенческого таргетинга с динтаблицами
Система поведенческого таргетинга — это сотни тысяч событий в секунду, требование обработки в режиме exactly-once, жёсткие ограничения по времени отклика, компромисс между скоростью и экономией ресурсов.
Разработчик YTsaurus рассказал, как построить такую систему на основе динамических таблиц. А также:
🔸 почему таблицы в памяти иногда тормозят из-за аллокатора
🔸 зачем внедрять xdelta
🔸 как именно устроены агрегатные колонки
🔸 как добиться, чтобы миллисекунды отклика в 99,9 перцентиле стали реальностью
Если нужно построить систему, способную обрабатывать миллиарды событий в день, — описанный подход давно работает в продакшне и позволяет решать реальные задачи.
Читать здесь: ссылка
👉 @BackendPortal
Что происходит, когда ты вводишь URL в браузер?
В процессе участвуют сам браузер, ОС компьютера, провайдер, сервер, где лежит сайт, и сервисы на этом сервере.
1. Вводишь адрес
Например: https://somewebsite.com/pagehttps:// — схема, говорит браузеру подключаться через TLS.somewebsite.com — домен, который указывает на IP сервера./page — путь к нужному ресурсу.
2. Поиск IP по домену
Браузер должен понять, к какому серверу идти. Для этого делается DNS-запрос. Сначала проверяются кэши (браузера, ОС, провайдера). Если IP нет, DNS идёт по цепочке: от корневых серверов до нужного уровня домена.
3. Установка TCP-соединения
Через TCP пакеты проходят по маршруту: браузер → роутер → провайдер → интернет-узлы → сервер с нужным IP. Чтобы ускорить процесс, сайты часто используют CDN — они кэшируют контент ближе к пользователю.
4. Отправка HTTP-запроса
После соединения браузер отправляет HTTP(s) запрос: стартовая строка (например, GET /page HTTP/1.1), заголовки, тело. По этим данным сервер понимает, что именно нужно клиенту.
5. Обработка запроса сервером
Сервер получает запрос, смотрит на заголовки, путь и тело. Для GET /page сервер находит ресурс, формирует ответ и возвращает его с HTTP-статусом (например, 200 OK).
6. Рендеринг ответа
Браузер получает ответ и заголовки, например Content-Type: text/html. Это говорит, что в теле HTML. Дальше браузер парсит HTML, подтягивает CSS, JS, картинки и строит финальную страницу.
👉 @BackendPortal
Вкратце современный стек разработки ПО
👉 @BackendPortal
Чем отличаются друг от друга архитектурные паттерны MVC, MVP, MVVM, MVVM-C и VIPER?
👉 @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 может воспроизвести нестандартные статусы и заголовки локально.
То есть часть «мелких зависимостей» от бэка снимается, команда двигается быстрее, а вы меньше отвлекаетесь на вспомогательные задачи.
🔥 VPN, который реально выручает — отличная находка
Устали от VPN, которые только обещают, но не работают? 😤
Скорость оставляет желать лучшего 📉, соединение постоянно рвется 😵, а нужные сайты отказываются открываться?
Тогда вам точно стоит обратить внимание на ProxyFable! 🚀
💥 Работает очень быстро. Сервис отлично подходит для просмотра YouTube, онлайн-игр и работы — без лагов и зависаний.
🛡 Анонимность на высоком уровне. Никаких логов, всё зашифровано. Можно спокойно пользоваться из любой точки мира.
🌍 Серверы в разных странах — США, Германия, Нидерланды. Всё работает стабильно, без перегрузов.
💸 Выгодная партнерская программа. За приглашение друзей можно получать реальные деньги на карту.
🎁 Сервис дает 2 дня бесплатного доступа — можно протестировать всё без привязки карты и сразу начать приглашать друзей.
💬Поддержка оперативная — отвечают быстро и по делу.
➡️ Протестировать сервис можно тут: @ProxyFable_bot
📡 Новости и обновления: @ProxyFableChannel
Жизненный цикл Pod в Kubernetes
👉 @BackendPortal
Настоящая задача уровня баз данных в сетевом мире.
У маршрутизаторов BPG почти миллион строк в таблицах маршрутизации.
При получении IP пакета нужно найти адрес назначения, отобрать все подходящие сети с применением маски, выбрать маршрут с минимальной стоимостью и определить следующий хоп для пересылки пакета.
Это должно выполняться за доли секунды.
👉 @BackendPortal
BrOk — графический дизайнер интеграционных процессов от AXENIX
🔥 BrOk — это low-code решение для работы с брокерами сообщений (Kafka, RabbitMQ, Artemis, Redis MQ, NATS), СУБД, REST-сервисами и хранилищами данных (ETCD, Redis). Всё управление — через единый GUI, без лишних CLI-команд.
Для кого: разработчики, DevOps и QA, которые настраивают интеграции, тестируют нагрузку или управляют обменом данными.
Что умеет BrOk:
🔸 Подключение к брокерам, БД, REST-API, ETCD и Redis в одном интерфейсе
🔸 Генерация сообщений по шаблонам для тестов
🔸 Low-code сценарии с ретраями и расписанием
🔸 Поддержка Postman и OpenAPI-коллекций
🔸 Инструменты для Kafka: KsqlDB, Connect, Schema Registry
🔥 Главное — BrOk распространяется бесплатно для некоммерческого использования.
Скачайте дистрибутив на официальном сайте и упростите разработку и тестирование сложных информационных систем уже сегодня!
Реклама. ООО «Акстим Тех». ИНН 6950259732
Говорят, что микросервисы вредны для планеты. 🌟
В статье рассматриваются стратегии как на уровне проектирования, так и на уровне эксплуатации, которые помогают сделать микросервисы более энергоэффективными.
Снижение высокого энергопотребления в микросервисах - тык
👉 @BackendPortal
В программировании система это набор правил, процессов и триггеров, которые помогают управлять рабочим процессом.
В этой статье Prankur Pandey разбирает ключевые принципы системного дизайна, которые можно применять и в коде, и в жизни.
В примерах используются джоб-борды и гейминг, а также рассматриваются проблемы роста, кэширование и CDN, API, теорема CAP и многое другое
👉 @BackendPortal
👨💻Ищем программистов, DevOps, QA. Релокейт, удалёнка, платим много!
Специально для Вас, собираем лучшие вакансии, только с прямыми контактами в Telegram!
👩💻 DevOps 👣 Go
👩💻 Java 👩💻 Python
🖼️ PHP 👩💻 Node.js
👩💻 C# 🤖 ML & DS
🔎 QA 🖥 SQL
👩💻 UX/UI 👩💻 Frontend
👩💻 Mobile 👩💻 Analyst
💼 1C
Подпишись чтобы не упустить свой шанс получить лучший оффер!
Какие паттерны проектирования реально нужны
Знать все паттерны не обязательно.
Но есть базовые, которые каждый разработчик должен освоить по мере роста, чтобы писать более качественный софт.
🔴 Junior Developer
Фокус на основе: создание объектов, чистые алгоритмы, понятные потоки событий.
1. Singleton — один экземпляр, глобальный доступ. Использовать осторожно, избегать скрытого состояния
2. Factory Method — делегирование создания объектов, скрытие деталей
3. Strategy — замена алгоритмов без if/else
4. Template Method — фиксированный алгоритм с настраиваемыми шагами
5. Observer — подписка на события без жесткой связки
Эти паттерны помогают писать более чистый и тестируемый код с самого начала.
🔴Mid-Level Developer
Следующий уровень —> умение управлять сложностью и добавлять гибкость.
1. Builder — пошаговое создание сложных объектов
2. Facade — единая точка входа в запутанную подсистему
3. Adapter — подгонка сторонних API под твой код
4. Proxy — прокси-объект для контроля доступа, ленивой загрузки или удаленного вызова
5. Decorator — добавление обязанностей во время выполнения без наследования
6. Command — обертывание действий в объекты (очередь, undo, логирование)
7. State — представление режимов как классов вместо флагов
Эти паттерны учат упрощать подсистемы, расширять поведение без наследования и моделировать процессы безопаснее.
🔴Senior Developer
Задача —> развивать системы безопасно и оптимизировать их под изменения и производительность.
1. Composite — одинаковое обращение к дереву «часть-целое» (меню, правила, цены)
2. Visitor — добавление операций к сложным структурам без редактирования классов
3. Bridge — разделение абстракции и реализации, независимое развитие
4. Flyweight — разделение внутреннего состояния для экономии памяти при множестве похожих объектов
5. Interpreter — небольшие DSL, разбор и выполнение простых грамматик
На этом уровне важно не количество паттернов, а умение выбирать.
Самое сложное это понять, когда их не стоит применять.
- Паттерны — это инструменты, а не правила.
- Неверный паттерн в неверное время создаст лишнюю сложность.
- Верный — сделает систему гибкой и готовой к будущим изменениям.
👉 @BackendPortal
Шпаргалка по структуре 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