То, что контейнер запущен, ещё не значит, что приложение работает корректно

Добавь полноценную проверку состояния (healthcheck). Пусть Docker сам разбирается, когда что-то ломается

👉 @BackendPortal

Запустить локальную базу данных PostgreSQL с помощью Docker проще простого

Нужно протестировать или разработать приложение? Просто:

→ Создайте изолированную среду без конфликтов с другими сервисами
→ Используйте официальный образ PostgreSQL — стабильность и совместимость гарантированы
→ Настройте пароль суперпользователя через переменные окружения (-e)
→ Пробросьте порт (-p), чтобы подключаться с вашей машины или других контейнеров
→ Всё запускается одной командой — Docker сам подтянет образ, если его ещё нет

👉 @BackendPortal

ЭТОТ ИНСТРУМЕНТ ПОМОГАЕТ ИИ ОРИЕНТИРОВАТЬСЯ ВО ВСЕЙ ВАШЕЙ КОДОВОЙ БАЗЕ

• Строит граф знаний, благодаря которому ИИ отслеживает связи между компонентами, а не перечитывает файлы заново
• Работает локально с Claude Code, Cursor и более чем 20 другими ИИ-агентами для программирования

Репозиторий: https://github.com/Graphify-Labs/graphify

👉 @BackendPortal

SCREENPIPE ВОШЁЛ В ЧИСЛО САМЫХ ПОПУЛЯРНЫХ RUST-РЕПОЗИТОРИЕВ НА GITHUB

• Записывает активность на устройстве, чтобы дать ИИ доступ к долгосрочной памяти с возможностью поиска
• Работает локально, ориентирован на конфиденциальность и уже набрал более 20 000 звёзд на GitHub

Репозиторий: https://github.com/screenpipe/screenpipe

👉 @BackendPortal

Представили OpenShip.

Open-source-платформа для создания, развёртывания, эксплуатации и масштабирования приложений на вашей собственной инфраструктуре.

Замените инструменты деплоя, управляемые сервисы и инфраструктурные процессы одной open-source-платформой.

Доступно уже сегодня:

— Почтовый сервер (встроен, запускается в один клик)

• Работает на вашем собственном VPS
• Неограниченное количество доменов
• Неограниченное количество почтовых ящиков
• Современный веб-интерфейс для почты в комплекте
• Подключение через Gmail, Outlook, Apple Mail, Thunderbird или любой IMAP/SMTP-клиент
• Отправка писем напрямую из ваших приложений по SMTP
• Без подписок на почтовые ящики и платы за API
• Высокая доставляемость писем

— Деплой:

• Деплой любого стека
• Деплой на основе Git
• Деплой без простоев
• Откат в один клик
• Окружения Development, Staging и Production
• Деплой нескольких веток с изолированными окружениями
• Деплой на VPS, выделенные серверы, облачные виртуальные машины или домашнюю инфраструктуру

— Сервисы:

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

• Supabase
• PostgreSQL
• MySQL
• MariaDB
• MongoDB
• Redis
• MinIO
• Meilisearch
• Qdrant
• RabbitMQ
• Kafka
• ClickHouse
• Elasticsearch
...а также разворачивайте любые другие сервисы рядом со своими приложениями.

— Эксплуатация:

• Логи деплоя в реальном времени
• Логи запросов в реальном времени
• Аналитика трафика в реальном времени
• Автоматическое резервное копирование
• Мониторинг
• Управление секретами
• Домены
• Автоматический SSL
• Переменные окружения
• Задачи по расписанию
• Проверки состояния

— Несколько окружений:

• Отдельные окружения Development, Staging и Production
• Независимый деплой каждой ветки
• Тестирование изменений перед выходом в Production
• Изолированные сервисы, секреты и конфигурация для каждого окружения

— Безопасность и команды:

• Управление командами
• Ролевое управление доступом
• Правила разрешения и блокировки IP-адресов
• Ограничение частоты запросов
• Правила безопасности

— Удобство для разработчиков:

• Веб-панель управления
• Нативное десктопное приложение
• CLI
• REST API
• Поддержка MCP для ИИ-агентов: просто добавьте MCP, и ваш агент сможет выполнять работу за вас
• Управляйте своей инфраструктурой, не проводя всё время в SSH

— Скоро:

• Мультисерверная кластеризация приложений и баз данных
• Балансировка нагрузки в один клик
• Горизонтальное масштабирование на нескольких серверах
• Встроенная высокая доступность и автоматическое переключение при сбоях
• Масштабирование от одного VPS до кластера в рамках одного и того же рабочего процесса
• Просто добавляйте серверы. OpenShip сделает всё остальное.

Open source.

👉 @BackendPortal

Этот бесплатный инструмент превращает любую браузерную сессию в общий стрим, который можно смотреть вместе.

Он называется neko.

Он транслирует полноценный браузер с рабочим столом из Docker-контейнера через WebRTC, поэтому несколько пользователей могут одновременно наблюдать за одной сессией и управлять ею в реальном времени — вместо обычного шаринга экрана.

→ Совместное управление несколькими пользователями, а не только просмотр
→ Встроенная передача аудио, в отличие от Guacamole или noVNC
→ Подходит для совместных просмотров, удалённого тестирования и общих демо

Можно бесплатно развернуть на собственной инфраструктуре.

https://github.com/m1k1o/neko

👉 @BackendPortal

Как Netflix справляется с резкими скачками трафика

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

Вот как Netflix сохраняет надёжность:

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

● Балансировщик нагрузки распределяет трафик между несколькими серверами.

● Микросервисы независимо обрабатывают аутентификацию, рекомендации, воспроизведение и биллинг.

● Redis кэширует часто запрашиваемые данные, чтобы снизить нагрузку на базу данных.

● Kafka асинхронно обрабатывает события для аналитики и системы рекомендаций.

● Автомасштабирование добавляет или удаляет серверы в зависимости от объёма трафика.

● Проверки состояния автоматически исключают неработоспособные экземпляры из балансировки.

● Развёртывание в нескольких регионах позволяет сервису оставаться доступным, даже если целый регион выходит из строя.

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

👉 @BackendPortal

Дата-центры

На схеме показаны два дата-центра. В штатном режиме пользователи направляются через geoDNS, также называемый географической маршрутизацией, в ближайший дата-центр. При этом x% трафика приходится на US-East, а оставшиеся (100 − x)% — на US-West.

geoDNS — это DNS-сервис, который позволяет разрешать доменные имена в IP-адреса с учётом местоположения пользователя.

В случае серьёзного сбоя одного из дата-центров весь трафик перенаправляется в исправный дата-центр.

Технические сложности

> Перенаправление трафика
geoDNS можно использовать для перенаправления трафика в зависимости от местоположения пользователя.

> Синхронизация данных
Пользователи из разных регионов могут обращаться к разным базам данных и кэшам. При failover трафик может быть направлен в дата-центр, где нужные данные недоступны. Распространённая стратегия — реплицировать данные между несколькими дата-центрами.

> Тестирование и развёртывание
При конфигурации с несколькими дата-центрами важно тестировать сайт или приложение из разных географических локаций.

👉 @BackendPortal

Паттерн Outbox решает только половину проблемы.

Но что происходит на стороне consumer?

Outbox гарантирует, что событие будет опубликовано после коммита бизнес-транзакции.

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

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

Здесь помогает паттерн Inbox.

Consumer сохраняет ID сообщения и выполняет бизнес-операцию в рамках одной транзакции базы данных.

Если сообщение приходит повторно, consumer распознаёт его и пропускает дублирующую обработку.

Outbox защищает отправителя.

Inbox защищает получателя.

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

Доставка как минимум один раз + идемпотентная обработка.

Exactly-once delivery — чаще всего лишь обещание.

Поведение, эквивалентное exactly-once, — это уже архитектура.

👉 @BackendPortal

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

func get(s []int, i int) int { return s[i] }

Перед чтением s[i] компилятор внутренне добавляет сравнение индекса с len(s) и переход к panic, если индекс выходит за границы. Это две дополнительные инструкции при каждом вызове, которые нужны только для защиты от чтения за пределами слайса.

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

unsafe.Add(unsafe.Pointer(unsafe.SliceData(s)), i)

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

Это не значит, что теперь стоит повсюду использовать unsafe. По умолчанию компилятор защищает вас, но как только вы переходите к unsafe, эта защита исчезает. Одна ошибка — и вы получаете повреждение памяти.
Компиляторы — это всё-таки интересно, правда? Надеюсь, было полезно.

👉 @BackendPortal

Сегодня разработка ПО уже не ограничивается только классическим жизненным циклом SDLC. Инженерам всё чаще приходится работать сразу с двумя подходами: SDLC и ADLC.

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

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

SDLC при этом никуда не исчезает. На нём по-прежнему строятся обычные программные продукты вроде GitHub, Stripe, Notion и Slack.

Но с появлением Devin, Claude Code, Manus, OpenAI Operator и других агентных систем ADLC становится отдельной важной частью разработки.

Поэтому современному инженеру всё полезнее понимать оба подхода: как создавать традиционное ПО и как проектировать надёжных, безопасных и предсказуемых ИИ-агентов.

👉 @BackendPortal

Наткнулся в интернете на интересную мысль:

Первое правило программирования - не делай хуже, чем есть сейчас.

Есть принцип забора Честертона: если ты видишь забор посреди поля, может показаться, что он лишний, и захочется его убрать. Но если ты не знаешь, зачем он там, ты рискуешь ошибиться и дорого за это заплатить.

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

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

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

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

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

👉 @BackendPortal

При работе с JSONB знали ли вы, что следующие запросы функционально эквивалентны, но используют разные индексы?
Оба проверяют, что по пути user.city находится значение "Denver", но первый использует извлечение значения по пути и оператор сравнения, а второй — оператор вхождения.

B-tree индекс по выражению, использует операторы сравнения:

data->'user'->>'city' = 'Denver'

GIN-индекс, использует операторы вхождения:

data @> '{"user": {"city": "Denver"}}'

👉 @BackendPortal

Один из самых умных трюков для защиты данных, которые я видел в продакшене?

—> Временной RLS (Temporal RLS)

Row-Level Security — это функция PostgreSQL, позволяющая управлять тем, какие строки может видеть пользователь, прямо на уровне базы данных.

Вместо того чтобы фильтровать данные в коде приложения, RLS переносит контроль доступа в саму БД

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

Пример использования:

Финтех-компании нужно было дать аналитикам доступ к транзакциям, но с задержкой в 24 часа, чтобы снизить риск мошенничества и инсайдерской торговли

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

Как?

1. Включили RLS на таблице

2. Определили политику фильтрации строк

3. Включили принудительное применение RLS для всех обращений (необязательно, но рекомендуется)

Даже если кто-то подключится к базе напрямую через psql, BI-инструмент или SQL-клиент — он увидит только строки, старше 24 часов. Без исключений.

⏩Безопасность обеспечивается у источника

⏩Политики версионируются вместе со схемой

⏩Код приложения не участвует

Вывод:

RLS — это не только про фильтрацию арендаторов. С его помощью можно строить умные правила: задержка по времени, доступ по пользователям, мягкое удаление — и всё это реализуется самой БД

👉 @BackendPortal

CPU, GPU, TPU, NPU и LPU: в чём разница

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

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

GPU использует тысячи более простых ядер, которые параллельно выполняют одинаковые операции над разными данными. Именно поэтому GPU стали основной платформой для обучения нейросетей.

TPU ещё сильнее специализированы под AI. Их основа — массивы MAC-блоков, через которые веса, активации и промежуточные результаты передаются без постоянного обращения к памяти. Выполнением управляет компилятор, а сама архитектура изначально создавалась Google для нейросетевых задач.

NPU оптимизированы для энергоэффективного инференса на устройствах. Они используют MAC-массивы и встроенную SRAM, но работают с низкопотребляющей системной памятью вместо HBM. Такие процессоры устанавливают в смартфоны, ноутбуки, носимые устройства и IoT-системы. К этому типу относятся Apple Neural Engine и NPU от Intel.

LPU — архитектура Groq, созданная для обработки языковых моделей. Она исключает внешнюю память из критического пути: веса хранятся во встроенной SRAM, а выполнение полностью планируется компилятором. Это устраняет промахи кеша и накладные расходы на планирование во время работы.

Главный недостаток LPU — ограниченный объём памяти на одном чипе, поэтому для запуска крупной модели приходится объединять сотни процессоров. Однако это позволяет заметно снизить задержку.

Эволюция AI-железа движется от универсальных CPU к всё более специализированным архитектурам. На каждом этапе часть гибкости обменивается на производительность и энергоэффективность.

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

Та же проблема возникает и на программном уровне. Во время инференса LLM один GPU может ежедневно создавать терабайты KV-кеша, большая часть которого затем удаляется и пересчитывается. Это одна из причин высокой стоимости агентных нагрузок.


👉 @BackendPortal

Лето — неплохое время, чтобы навести порядок в базе данных. Например, проверить, не накопились ли в PostgreSQL бесполезные индексы.

pg_stat_user_indexes — системное представление PostgreSQL со статистикой использования индексов.

Со временем приложение меняется, вместе с ним меняются запросы, а старые индексы продолжают оставаться в базе. Некоторые из них больше не используются, другие срабатывают крайне редко. При этом каждый индекс создаёт дополнительную нагрузку при INSERT, UPDATE и DELETE.

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

SELECT * FROM pg_stat_user_indexes;

Основные поля:
idx_scan — количество сканирований индекса с момента последнего сброса статистики. 0 означает, что индекс не использовался.
last_idx_scan — время последнего сканирования. NULL означает, что индекс ни разу не использовался после сброса статистики.
idx_tup_read — общее количество записей индекса, возвращённых при сканировании.
idx_tup_fetch — количество актуальных строк таблицы, реально полученных через индекс.

В первую очередь стоит обратить внимание на крупные индексы с idx_scan = 0: они создают нагрузку при записи, но не приносят пользы запросам.

Однако удалять их сразу не стоит. Если недавно выполнялся pg_stat_reset(), статистика может охватывать слишком короткий период. Лучше дождаться полного типичного цикла нагрузки.

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

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

Для безопасного удаления лучше использовать:

DROP INDEX CONCURRENTLY index_name;

Так PostgreSQL удалит индекс без блокировки таблицы через ACCESS EXCLUSIVE.

👉 @BackendPortal

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