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

Вместо фиксированного пула I/O-воркеров, рассчитанного на условный «средний день», система будет масштабировать его по ситуации:

нагрузка растёт → очередь I/O увеличивается → PostgreSQL это замечает → запускает дополнительных воркеров → очередь разгружается → после снижения нагрузки лишние воркеры завершают работу.

Без ручного вмешательства и постоянного выделения ресурсов с запасом.

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

👉 @BackendPortal

Вышла новая статья о сборщике мусора Green Tea в Go.

Пейволл уже сняли, так что материал теперь можно прочитать бесплатно.

https://theconsensus.dev/p/2026/07/19/observing-gos-garbage-collector-old-and-new.html

👉 @BackendPortal

PostgreSQL 19 теперь умеет показывать активность асинхронного ввода-вывода прямо в EXPLAIN.

Это упрощает понимание:
→ где именно используется асинхронный I/O;
→ какие части плана обращаются к хранилищу;
→ получает ли запрос преимущество от асинхронного чтения.

Меньше догадок и больше прозрачности в том, что PostgreSQL делает под капотом плана выполнения запроса.
В PostgreSQL 18 появился асинхронный I/O.

А в PostgreSQL 19 стало проще увидеть, как он работает.

👉 @BackendPortal

Один из лучших инструментов для создания диаграмм в разработке — и при этом бесплатный и совместимый с GitHub.

Подходит для UML-диаграмм, блок-схем и описания процессов.

Готовые схемы можно экспортировать в изображения, PDF, HTML и другие форматы.

→ http://app.diagrams.net

👉 @BackendPortal

Postgres 19 исправляет AUTOVACUUM

Autovacuum удаляет мёртвые строки и поддерживает таблицы в нормальном состоянии. Теперь PostgreSQL умеет:

→ Запускать несколько autovacuum-воркеров
→ Оценивать таблицы по уровню риска
→ В первую очередь обрабатывать таблицы, которым очистка нужна срочно
→ Выполнять VACUUM для нескольких таблиц параллельно

👉 @BackendPortal

Morning Banger: новый выпуск PING от APNIC про загадочное поведение DNS-запросов.

Почти каждый DNS-запрос, который видят APNIC Labs, появляется дважды, а иногда и больше. В обычный день система фиксирует около 150 млн уникальных DNS-меток, но получает примерно 270 млн запросов.
Почему DNS постоянно повторяет одни и те же запросы?

В новом выпуске PING George Michaelson и главный научный сотрудник APNIC Geoff Huston разбирают, что происходит внутри DNS-инфраструктуры и почему дублирование запросов — это не просто лишний трафик, а часть поведения самой системы.

Причины могут быть разными: кэши, прокси, повторные обращения браузеров, особенности DNSSEC и работа recursive resolver’ов. Повторный запрос может показывать, сколько резолверов стоит за пользователем и какие механизмы участвуют в разрешении домена.

Интересный разбор того, как на самом деле работает один из фундаментальных слоёв интернета.
https://blog.apnic.net/2026/07/23/podcast-dns-query-duplication/

👉 @BackendPortal

Планировщик запросов PostgreSQL использует динамическое программирование, чтобы подобрать наиболее дешёвый порядок JOIN при объединении нескольких таблиц.

Пожалуй, один из тех редких моментов, когда dynamic programming встречается не в задачке с LeetCode, а внутри системы, которой разработчики пользуются каждый день.

https://internals-for-interns.com/posts/postgres-query-planner/

👉 @BackendPortal

Задержки это смерть от тысячи мелких порезов.

Так что чините. Начните с базы: один плохой запрос легко добавляет полсекунды, а на тысячах запросов это превращается в катастрофу. Не используйте SELECT *, добавляйте индексы, убивайте N+1 и всегда проверяйте запросы через EXPLAIN.

Дальше посмотрите на сетевые прыжки. Каждый переход через цепочку сервисов добавляет задержку, поэтому мелкие сервисы иногда лучше объединить. Хорошая идея — использовать BFF.

Кэш тоже обязателен. Если данные не меняются, нет смысла тянуть их заново. Сессии, каталоги, конфиги — держите их горячими. Протухший кэш плохо, но отсутствие кэша почти всегда хуже.

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

И не таскайте лишние данные. Убирайте ненужные поля, сжимайте ответы, делайте пагинацию и оптимизируйте картинки.

Скорость это не дополнительная фича, а фундамент нормального UX.

👉 @BackendPortal

Fleetbase — опенсорсная модульная ОС для логистики и управления цепочками поставок.

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

В общем, self-hosted логистика для тех, кому обычного CRUD уже недостаточно.

https://github.com/fleetbase/fleetbase

👉 @BackendPortal

Несколько алгоритмов, которые я периодически заставляю себя повторять, чтобы не забыть, как они работают:

• Kadane’s → максимальная сумма подмассива
• Rabin–Karp → поиск подстроки с помощью хеширования
• Topological Sort → топологическая сортировка DAG
• Prim’s → минимальное остовное дерево
• Kruskal’s → MST с Union-Find
• Dijkstra’s → кратчайший путь без отрицательных весов
• Bellman–Ford → кратчайший путь с отрицательными весами
• Tarjan’s → компоненты сильной связности
• Backtracking → решение Sudoku

К этим алгоритмам я продолжаю возвращаться даже спустя годы.

А какие алгоритмы вы до сих пор периодически повторяете?

👉 @BackendPortal

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

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

1. The Google File System (2003)

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

Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf

2. Dynamo: Amazon’s Highly Available Key-Value Store (2007)

Почему стоит прочитать: исчерпывающий разбор того, как пожертвовать согласованностью ради высокой доступности — AP в теореме CAP. В статье изложены ключевые паттерны, лежащие в основе масштабируемых NoSQL-хранилищ: консистентное хеширование, векторные часы, gossip-протоколы и настраиваемый кворум для операций чтения и записи.

Ссылка: https://allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

3. In Search of an Understandable Consensus Algorithm (Raft) (2014)

Почему стоит прочитать: Paxos печально известен тем, насколько сложно его понять и корректно реализовать, тогда как Raft делает концепцию реплицируемых конечных автоматов более доступной. Алгоритм разбивает задачу консенсуса на отдельные подзадачи, которые легко анализировать: выбор лидера, репликацию журнала и обеспечение безопасности.

Ссылка: https://raft.github.io/raft.pdf

4. Spanner: Google’s Globally-Distributed Database (2012)

Почему стоит прочитать: статья показывает, как добиться строгой сериализуемости и внешней согласованности между дата-центрами по всему миру. Секрет — API Google TrueTime, ограничивающий неопределённость времени с помощью синхронизированных GPS-приёмников и атомных часов.

Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf

5. Time, Clocks, and the Ordering of Events in a Distributed System

Почему стоит прочитать: на физическое время нельзя полагаться при работе с независимыми узлами. Лэмпорт вводит логические часы и фундаментальное отношение «произошло до» (happened-before), лежащее в основе упорядочивания событий в современных распределённых сетях.

Ссылка: https://amturing.acm.org/p558-lamport.pdf

👉 @BackendPortal

Автор pgrust — PostgreSQL, переписанного на Rust, — рассказал о четырёх распространённых причинах сбоев PostgreSQL:

1. VACUUM и переполнение счётчика идентификаторов транзакций
2. Лимиты подключений и модель «один процесс на подключение»
3. Неудачные планы выполнения запросов — интересно, насколько здесь помогут новые хинты для запросов в PostgreSQL 19
4. Статистика для JSON

Я потратил некоторое время на изучение первых двух проблем, но с двумя последними знаком хуже.

Раздел о JSON оказался интересным. Любопытно, устраняют ли расширения PostgreSQL вроде DocumentDB некоторые из этих ограничений.

Стоит прочитать, если вы работаете с PostgreSQL.

https://malisper.me/the-four-horsemen-behind-thousands-of-postgres-outages/

👉 @BackendPortal

Покрывающий индекс содержит все столбцы, которые нужны запросу.

Сюда входят как поля для фильтрации и сортировки (ключ индекса), так и дополнительные поля, которые нужны в SELECT. Их можно добавить через INCLUDE.

Ищите в плане выполнения строку:
Heap Fetches: 0

Это означает, что PostgreSQL смог выполнить запрос полностью из индекса и не обращался к основной таблице (heap).

👉 @BackendPortal

GoProxy — это высокопроизводительный прокси-сервер с поддержкой HTTP, HTTPS, SOCKS5 и SS-протоколов.

Он умеет делать балансировку нагрузки между прокси, пробрасывать TCP/UDP-порты и создавать SSH-туннели.

Также его можно использовать как reverse proxy, чтобы открывать доступ к локальным сервисам, которые находятся за NAT или файрволом.

https://github.com/snail007/goproxy

👉 @BackendPortal

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

И эта статья до сих пор остаётся одним из лучших материалов по теме:

• Как на самом деле работает оперативная память
• Кеши процессора и почему от них так сильно зависит производительность
• Практические методы оптимизации
• Инструменты для измерения того, что реально происходит в системе

Автор — Ульрих Дреппер из Red Hat.

Материалу почти 20 лет, но он до сих пор актуален.

Доступно бесплатно:

https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

👉 @BackendPortal

Кэшировать или не кэшировать?

Это вопрос, с которым бэкендер сталкивается каждый день.

Большинство инженеров кэшируют слишком много.
Это ленивая инженерия.

Вот небольшой фреймворк, чтобы принимать решение правильно:

I. Данные часто запрашиваются?
II. Их дорого получать?
III. Они изменчивые?
IV. Объём данных большой?
V. Влияет ли это на воспринимаемую пользователем задержку?
VI. Безопасно ли кэшировать?
VII. Есть ли механизм протухания или инвалидации кэша?

👉 @BackendPortal

Большинство воспринимает Spring Boot просто как фреймворк для создания REST API.

Но за ним скрывается гораздо более крупная экосистема 👇

• Spring Core и внедрение зависимостей
• Spring MVC и WebFlux
• JPA, Hibernate и базы данных
• Безопасность с JWT и OAuth 2.0
• Kafka и RabbitMQ
• Redis и распределённое кэширование
• Docker, Kubernetes и облачные платформы
• Мониторинг с Actuator, Prometheus и Grafana

Spring Boot упрощает настройку проекта, а понимание всех стоящих за ним уровней помогает стать сильнее как бэкенд-разработчик.

Фреймворк позволяет быстро начать работу.

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

#SpringBoot #Java #Backend #SoftwareEngineering #Microservices #DevOps

👉 @BackendPortal