Если делаешь приложение или API, где важна скорость ответа, Redis может сильно разгрузить бэкенд.

Вместо того чтобы каждый запрос снова лез в базу данных, часто запрашиваемые данные кладутся в память. Следующие запросы получают их сразу из кэша, без лишних обращений к БД.
Маниш разобрал, как работает in-memory кэширование в Redis, как его настроить и как внедрить на реальном примере.

Полезный материал для тех, кто хочет уменьшить задержки, снизить нагрузку на базу и ускорить API.
https://freecodecamp.org/news/how-in-memory-caching-works-in-redis/

👉 @BackendPortal

Один вопрос по Kubernetes, который мне попадается снова и снова на собеседованиях:

Что происходит с запросом на пути от интернета до Pod'а?

Обычно ответ выглядит так:
User → ALB → Ingress → Service → Pod
И вроде всё правильно.

Но самое интересное начинается после этого.
Следом обычно спрашивают:
• Кто выбирает Pod, который получит запрос?
• Чем на самом деле занимается kube-proxy?
• Как работают iptables и IPVS?
• Зачем нужен CNI-плагин?
• Что будет с трафиком, если kube-proxy упадёт?

Для меня одним из самых полезных инсайтов было вот что:
Service в Kubernetes сам по себе не балансирует трафик.
kube-proxy создаёт правила iptables/IPVS на нодах, и именно они направляют запросы в живые Pod'ы.

Ещё интереснее становится, когда речь заходит об отказах.
Если kube-proxy упадёт, трафик обычно не перестаёт ходить мгновенно. Существующие правила уже находятся в ядре Linux и продолжают работать.

Ломается другое: Kubernetes больше не может обновлять эти правила, когда появляются новые Pod'ы, удаляются старые или меняются Service.

Смешно, но именно такие базовые вопросы чаще всего вскрывают самые глубокие пробелы в понимании Кюбернетеса.

👉 @BackendPortal

Foundations of Computer Science от Alfred Aho и Jeffrey Ullman доступна бесплатно онлайн.
Классический учебник по информатике, который охватывает:

• конечные автоматы
• формальные языки
• теорию вычислений
• основы алгоритмов и вычислительных моделей

Хорошая отправная точка для тех, кто хочет разобраться в фундаментальных концепциях Computer Science, лежащих в основе компиляторов, языков программирования и теории вычислений.

Книга:
http://infolab.stanford.edu/~ullman/focs.html

#computerscience #book #theory #cs

👉 @BackendPortal

Если вы программируете на Windows, стоит обратить внимание на Windows Developer Config от Microsoft.

Инструмент позволяет подготовить машину для разработки одной командой.

Что умеет:

✓ Настраивает WSL и Ubuntu
✓ Устанавливает Windows Terminal
✓ Ставит Node.js, Python, Rust, Go, Java, .NET, PHP и другие инструменты
✓ Автоматизирует настройку рабочего окружения

Проект полностью открытый и доступен на GitHub.

👉 @BackendPortal

Salesforce внедрила 20 000 корпоративных AI-агентов.

Главный вывод оказался неожиданным:

Для классического ПО 90% работы происходит до релиза.

Для AI-агентов всё наоборот — 90% работы начинается после запуска.

В интервью с Джоном Кучерой, CPO Agentforce, обсудили, что отличает агентов, которые приносят реальную пользу бизнесу, от тех, что так и остаются красивым демо.

Одна из ключевых мыслей:

Команды, которые считают запуск финишной чертой, застревают на стадии пилота.

Команды, которые воспринимают запуск как стартовую точку, масштабируют решения дальше.

В материале разбирают:

→ Почему большинство корпоративных агентов терпят неудачу
→ Что нужно подготовить до запуска: scope, KPI и guardrails
→ Как выглядит feedback loop, без которого невозможно масштабирование
→ Три анти-паттерна, выявленных на основе 20 000 внедрений
→ Куда движется архитектура агентных систем

👉 @BackendPortal

Многие инженеры добавляют кэш, чтобы решить проблему производительности.
В итоге получают две системы хранения данных. (Появляется второй источник истины.)

Вот в чём разница:
Write-Through Cache → приоритет консистентности данных
Write-Behind Cache → приоритет производительности, допускается временная неконсистентность и риск потери данных
Write-Through — кэш и база данных обновляются одновременно при каждой записи.
(Представьте доску, которая в реальном времени синхронизируется с общим документом.)
Write-Behind — данные сначала записываются в кэш, а затем позже сбрасываются в базу данных.
(Представьте, что вы делаете заметки на доске, а в общий документ переносите их только в конце дня.)

Практическое правило:
Если устаревшие данные недопустимы → используйте Write-Through.
Если критична скорость записи → используйте Write-Behind.

👉 @BackendPortal

Твой запрос к JSONB — не медленный. Ты просто используешь не тот индекс.

Допустим, ты хранишь события вот так:

{
  "user_id": "123",
  "status": "completed",
  "source": "mobile"
}

И фильтруешь их примерно так:

SELECT * FROM events WHERE payload @> '{"status":"completed"}';

Ты повесил B-Tree индекс на всю колонку payload.

Это не сработает.

PostgreSQL не умеет эффективно оптимизировать глубокие запросы к JSONB через B-Tree.
В итоге он каждый раз делает полный скан таблицы.

Чтобы это починить — нужен GIN-индекс (Generalized Inverted Index).

PostgreSQL создаёт инвертированный индекс:

🔸Разбивает каждый JSONB-объект на ключи и значения,
🔸Мапит их на ID строк,
🔸И вместо полного скана сразу прыгает к нужным совпадениям.

Если не делаешь запросы на вхождение (@>), добавь опцию jsonb_path_ops — индексы будут компактнее и быстрее.

Быстрее. Меньше. Чище.

👉 @BackendPortal

Я видел, как инженеры с 10-летним опытом проваливали собеседования по System Design на Senior-позиции.

И ошибка почти всегда одна и та же.

❌ «Наша архитектура данных — это React + Node.js + MongoDB»

✅ «Мы используем микросервисную архитектуру с событийным взаимодействием между сервисами, REST API и документо-ориентированной базой данных для обеспечения масштабируемости и гибкости»

Вы потеряете баллы, если будете описывать свой стек технологий вместо архитектурного подхода и причин, по которым были приняты те или иные решения.

Более правильный подход на архитектурном интервью:

1. Начните с ключевых принципов.

Например: «Наша система построена на event-driven подходе, чтобы сервисы оставались слабо связанными друг с другом».

2. Объясните компромиссы.

Например: «Мы выбрали eventual consistency вместо строгой консистентности, чтобы обеспечить высокую доступность системы».

3. Только после этого переходите к инструментам, если это необходимо.

Например: «Для реализации этого подхода мы используем Kafka».

Архитектура — это стратегия: что, зачем и когда.

Инструменты — это тактика: как именно это реализовано.

Архитектура — стратегический уровень. Инструменты — тактический.

Хорошая архитектура переживает смену инструментов.

👉 @BackendPortal

Хочешь разобраться в распределённых системах с нуля?

Начни с этих 10 тем:

Distributed Systems Reading List
https://github.com/theanalyst/awesome-distributed-systems
System Design Primer
https://github.com/donnemartin/system-design-primer
MIT 6.824 (Distributed Systems)
https://github.com/chaozh/MIT-6.824
System Design 101
https://github.com/ByteByteGoHq/system-design-101
Awesome Scalability
https://github.com/binhnguyennus/awesome-scalability
Raft Consensus Visualization https://github.com/ongardie/raftscope
Apache Kafka https://github.com/apache/kafka
Apache Cassandrahttps://github.com/apache/cassandra
etcd github.com/etcd-io/etcd

👉 @BackendPortal

Папка /internal в Go — одна из самых неправильно понятых вещей в структуре проекта.
Многие используют её один раз на верхнем уровне, просто чтобы спрятать код от внешнего мира.
Но мало кто знает главное.

internal можно вкладывать в internal.
И это меняет всю идею.

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

Так ты собираешь модульный монолит не из “папок с кодом”, а из жёстко изолированных блоков, где каждый живёт в своём контуре.

👉 @BackendPortal

Многие разработчики путают эти 3 HTTP-метода:

PUT
PATCH
POST

Самый простой способ запомнить:

POST → создать новый ресурс
POST /users
Создаёт нового пользователя.

PUT → полностью заменить ресурс
PUT /users/123
Если отправить только имя, остальные поля могут быть перезаписаны, потому что PUT подразумевает замену всего объекта целиком.

PATCH → обновить только изменённые поля
PATCH /users/123
Отправляешь только:
{ "email": "[new@example.com }

Обновится только email.

Короткое правило:

POST = создание
PUT = полная замена
PATCH = частичное обновление

Мнемоника:

POST → отправить новый объект
PUT → поставить новую версию вместо старой
PATCH → наложить патч на существующий объект

Правильный выбор HTTP-метода делает API более предсказуемым, REST-совместимым и проще в поддержке.


👉 @BackendPortal

Наткнулся на полезный open-source Email SDK

Он позволяет отправлять письма через единый API вместо того, чтобы писать отдельную интеграцию под каждого почтового провайдера.

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

Подходит для:

* SaaS-продуктов;
* веб-приложений;
* AI-автоматизаций;
* AI-инструментов, которые используют email-уведомления, рассылки или почтовые workflow.

Исходники:
github.com/opencoredev/email-sdk

👉 @BackendPortal

Одна из самых детальных шпаргалок для Backend-разработчика на русском языке. Внутри: от базового устройства интернета и ПК, до работы с базами данным, разработки API и тестирования продуктов.

Весь материал преисполнен разными таблицами и картинками для лучшего усвоения, вся информация подаётся кратко и понятно, а если захотите изучить детальнее — везде есть ссылки на источники.

👉 @BackendPortal

Нашёл GitHub-репозиторий, который помогает AI-агентам не сжигать токены впустую.

Называется Headroom.

Его создал Теджас Чопра, инженер из Netflix.

Идея простая: Headroom сжимает всё, что читает AI-агент, ещё до того, как данные попадут в LLM.

Например:

- вывод инструментов;
- логи;
- файлы;
- RAG-чанки;
- результаты поиска по коду;
- историю диалога.

По словам автора, это позволяет сократить расход токенов на 60–95% без потери качества ответов.

Сейчас Headroom можно использовать как:

- библиотеку для Python и TypeScript;
- локальный прокси;
- MCP-сервер;
- обёртку для Claude Code, Codex, Cursor, Aider и Copilot.

Если твой AI-агент становится дорогим, медленным или начинает теряться в огромных логах, на этот проект стоит взглянуть.

GitHub: https://github.com/tejaschopra/headroom

Спасибо за внимание.

👉 @BackendPortal

Как правильно работать с резервным копированием в облаке?

25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками.

⚫️Развеем мифы, разберём лучшие современные подходы и инструменты.

⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов.

⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы.

Зарегистрируйтесь, чтобы не пропустить!

⏰ 25 июня в 14:00 (мск)

✅ Зарегистрироваться

Мелкие архитектурные решения в софте могут сильно влиять на производительность.

Хороший пример — Array of Structs (AoS) против Struct of Arrays (SoA). Казалось бы, небольшое различие в организации данных в памяти, но оно радикально меняет эффективность использования кэша процессора и частоту cache hit'ов.

В результате разница в производительности может достигать целого порядка.

Похоже на выбор между построчным и колоночным хранением данных в СУБД. Всё упирается в паттерны доступа: OLTP и OLAP требуют разных подходов.

У Farad вышла отличная статья на эту тему — читается быстро и объясняет всё на понятных примерах. Ссылка ниже.

https://fzakaria.com/2026/06/01/every-byte-matters

👉 @BackendPortal

Избегать SQL — значит избегать настоящего бэкенда.

API меняются.
Фреймворки уходят в историю.
Базы данных переживают миграции, переписывания и смену стека.

Большинство проблем с производительностью на бэкенде возникают не из-за медленного кода приложения.

Обычно виноваты:

* плохие запросы;
* отсутствующие индексы;
* неудачная схема БД;
* слабая модель данных;
* неправильные паттерны чтения и записи.

Отсутствующий индекс не лечится микросервисами.

Дублирование данных не исправляется кэшем.

Медленные отчёты не ускоряются переписыванием API.

Если ты не понимаешь ACID, уровни изоляции, блокировки, дедлоки, индексы, партиционирование и планы выполнения запросов, рано или поздно система начнёт разваливаться под нагрузкой.

SQL — это не опция.

Хорошее знание SQL делает тебя сильнее в проектировании систем, распределённых системах, производительности и надёжности.

Изучи SQL.

Всё остальное строится поверх него.

👉 @BackendPortal

ИИ не уравнял всех разработчиков.

Он просто разделил рынок на несколько направлений, и многие до сих пор не поняли, в каком из них находятся.

Несколько лет назад быть сеньором означало быстро писать качественный код. Сегодня эту планку может преодолеть практически любой, кто умеет пользоваться современными ИИ-инструментами.

Что остаётся после этого?

1. Оркестраторы

Люди, которые проектируют процесс целиком.

Они определяют архитектуру, выбирают инструменты, продумывают точки отказа и решают, что должно происходить, когда что-то ломается.

Они не обязаны писать каждую строчку кода.

Они отвечают за систему в целом.

2. Системные инженеры

ИИ отлично генерирует код.

Но он не понимает, что произойдёт с базой данных при росте нагрузки в 10 раз, почему один пропущенный индекс способен положить прод через полгода или где появится узкое место после очередного релиза.

Чем быстрее генерируется код, тем больше потенциальный радиус поражения ошибок.

Поэтому люди, которые понимают производительность, надёжность и устройство систем, стали только ценнее.

3. Переводчики между бизнесом и технологиями

ИИ сильно сократил путь от идеи до реализации.

Но он не умеет определять, какие идеи вообще стоит реализовывать.

Эти люди понимают пользователей, рынок, продуктовые ограничения и умеют превращать размытые бизнес-задачи в конкретные технические решения.

Обычно они работают тихо.

Их редко замечают, пока они не уходят.

Мне кажется, главный эффект ИИ оказался не в замене разработчиков.

Он сделал гораздо заметнее разницу между теми, кто просто пишет код, и теми, кто проектирует системы, принимает решения и отвечает за результат.

👉 @BackendPortal