Немного разобрался с тем, как работают блокировки в PostgreSQL. Главный вывод: разные SQL-команды захватывают разные режимы блокировок, и многие из них специально сделаны совместимыми друг с другом, чтобы минимизировать конкуренцию за блокировки.

Даже обычный SELECT захватывает блокировку, которая препятствует выполнению некоторых «тяжёлых» операций (например, VACUUM FULL, REINDEX и т. п.). Оказалось, существует удивительно много сочетаний SQL-команд, которые могут или не могут выполняться одновременно.

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

👉 @BackendPortal

Git: merge vs rebase

А что предпочитаете вы ?

👉 @BackendPortal

Прикол: большинство разработчиков до сих пор не знают, что такое вообще существует.

Буквально полноценный браузер Chromium можно запустить прямо в терминале 🤯

Он поддерживает WebGL и WebGPU, запускается примерно за секунду, работает с частотой до 60 FPS и практически не потребляет ресурсы процессора в режиме простоя. Браузер также работает по SSH без необходимости в оконном сервере, а ещё в нём можно смотреть YouTube прямо из терминала.

Да, YouTube действительно можно смотреть прямо в терминале.

https://github.com/fathyb/carbonyl

👉 @BackendPortal

Golang: Можно было бы ожидать, что лёгкий мьютекс Go окажется быстрее реализации на основе pthread, но на практике всё наоборот.

Solod — подмножество Go, которое транслируется в C, — использует мьютексы pthread. В бенчмарке, где восемь потоков многократно захватывают и освобождают один и тот же мьютекс, реализация на pthread показала производительность почти в три раза выше, чем мьютекс Go.

👉 @BackendPortal

Создавайте первоклассную документацию для своего API или проекта.

Starlight предлагает всё необходимое: высокую скорость благодаря Astro, встроенную оптимизацию для SEO, доступность и поиск, а также поддержку Markdown, MDX и нескольких языков.

→ http://starlight.astro.build/es

👉 @BackendPortal

Чёрт… Это может перевернуть всё представление об эмуляторах AWS.

Команда разработчиков отказалась от привычного подхода к созданию эмуляторов AWS и представила Floci.
Это один исполняемый файл на Go размером всего 13 МиБ, который менее чем за 1 секунду запускает 45 сервисов AWS (S3, Lambda, DynamoDB, SQS, SNS, IAM, CloudFormation, Step Functions и другие). Никакого Docker. Никакого LocalStack. Никаких счетов за AWS. Никаких 4 ГБ оперативной памяти, занятых контейнерами. Никакого ожидания по 30 секунд.
Достаточно скачать исполняемый файл, запустить его — и у вас локально работает практически вся инфраструктура AWS.

https://github.com/floci-io/floci

👉 @BackendPortal

> Допустили ошибку в коммите? Вот как понять, что делать дальше.

Задайте себе вопрос: «Этот коммит уже попал в общий репозиторий?»

Если ДА → используйте git revert

- git revert создает новый коммит, который отменяет изменения предыдущего.
- Исходный коммит остается в истории.
- Команда всегда может увидеть, что именно было отменено и когда.

Если НЕТ → используйте git reset

- git reset удаляет коммиты так, будто их никогда не существовало.
- Переписывает историю проекта, перемещая указатель HEAD.
- Позволяет сохранить чистую и понятную историю Git до того, как изменения будут опубликованы.

👉 @BackendPortal

А кто-о-о это сделал: они полностью переписали PostgreSQL на Rust и он уже проходит 100% официальных тестов PostgreSQL 😔

Важно: это не форк, а полностью новая реализация с нуля на Rust, которая на данный момент:

• Проходит все 46 066 запросов из regression suite PostgreSQL 18.3.
• Совместима на уровне диска (можно запустить её напрямую с вашим текущим каталогом данных).
• Имеет рабочее демо в браузере.

Цель проекта — сделать одну из самых сложных баз данных в мире значительно проще для модификации, расширения и оптимизации изнутри, используя Rust и AI-assisted programming.

И самое безумное: уже существует WIP-версия (пока не опубликована), которая обещает быть на 50% быстрее на транзакционных нагрузках и примерно в 300 раз быстрее на аналитических нагрузках.

РЕПО 👇

https://github.com/malisper/pgrust

👉 @BackendPortal

Rate Limiting ≠ Throttling ≠ Backpressure

Эти три термина часто используют как взаимозаменяемые…

Но на самом деле они решают совершенно разные задачи масштабирования.

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

- Rate Limiting → ограничивает количество запросов, которые клиент может отправить.
- Throttling → ограничивает скорость обработки запросов системой, когда она находится под высокой нагрузкой.
- Backpressure → позволяет медленному потребителю сигнализировать быстрому производителю, чтобы тот снизил скорость и не перегружал систему.

Простая шпаргалка

- Rate Limiting = ограничение количества запросов.
- Throttling = замедление обработки.
- Backpressure = управление потоком данных.

Где используется каждый из подходов?

Rate Limiting

Используется в:

- API Gateway
- Публичных API
- Эндпоинтах авторизации
- Защите от злоупотреблений и DDoS-атак

Типичный ответ сервера:

HTTP/1.1 429 Too Many Requests

Throttling

Используется в:

- Фоновых задачах
- Сервисах с высокой нагрузкой на базу данных
- CPU-интенсивных операциях
- Защите зависимых сервисов во время всплесков трафика

Backpressure

Используется в:

- Kafka-консьюмерах
- Reactive Streams
- Событийно-ориентированных архитектурах
- Стриминговых конвейерах обработки данных

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

Пример из реальной жизни

Представьте платформу по продаже билетов на концерт во время старта продаж.

Rate Limiting

Каждый пользователь может отправить не более 100 запросов в минуту.

Throttling

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

Backpressure

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

Самое распространённое заблуждение

- Rate Limiting защищает API от слишком активных клиентов.
- Throttling защищает сам сервис от перегрузки.
- Backpressure защищает потребителей данных от слишком быстрых производителей.

Это не взаимоисключающие механизмы — они часто используются совместно.

Фраза, которую стоит запомнить

- Rate Limiting — *слишком много запросов.*
- Throttling — *обрабатывай медленнее.*
- Backpressure — *я не успеваю, притормози.*

Эти три концепции лежат в основе построения масштабируемых систем, таких как Netflix, Uber, Amazon и событийно-ориентированных архитектур на базе Kafka.

Сохраните эту шпаргалку — она пригодится каждому backend-разработчику и всем, кто изучает проектирование высоконагруженных систем.

👉 @BackendPortal

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

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

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

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

Как это обычно реализуют?
Один из самых распространённых вариантов — разместить перед приложением API Gateway или Reverse Proxy.

Этот компонент принимает запросы и решает, куда их направить:
в монолит;
в новый микросервис.

Так старая и новая системы могут сосуществовать на протяжении всей миграции.

👉 @BackendPortal

Системный дизайн: Архитектура с одним сервером

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

Обычно всё начинается с простого варианта: все компоненты работают на одном сервере.

Посмотрим, как проходит запрос:
> Пользователь обращается к api.mysite.com через веб-приложение или мобильное приложение.
> DNS преобразует доменное имя в IP-адрес 27.220.30.232.
> Запрос поступает на единственный веб-сервер.
> Сервер выполняет всё самостоятельно:
обрабатывает API-запрос;
выполняет бизнес-логику;
обращается к базе данных.
> Сервер отправляет пользователю HTML-страницу или JSON-ответ для дальнейшего отображения.

👉 @BackendPortal

Новый сервис, для конверта документов в Markdown: https://docs.context.dev/api-reference/utility/parse

Достаточно сделать один API-запрос: отправить содержимое файла и получить на выходе Markdown с сохранённой структурой, ссылками и порядком текста.

Сервис поддерживает PDF, Word, Excel, PowerPoint, HTML, CSV, изображения, исходный код и многие другие форматы. Если документ представляет собой скан или фотографию, встроенный OCR автоматически распознает текст.

👉 @BackendPortal

Системный дизайн: База данных

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

- один для обработки веб- и мобильного трафика — веб-уровень (web tier);
- другой для базы данных — уровень данных (data tier).

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

Какую базу данных использовать?

Можно выбрать между традиционной реляционной базой данных — RDBMS, или SQL-базой данных — и нереляционной базой данных — NoSQL.

Реляционные базы данных представляют и хранят данные в виде таблиц и строк. С помощью SQL можно выполнять операции JOIN между различными таблицами базы данных.

Нереляционная база данных может быть подходящим выбором, если:

- приложению требуется сверхнизкая задержка;
- данные неструктурированы или не имеют связей;
- требуется только сериализация и десериализация данных — JSON, YAML и т. д.;
- необходимо хранить огромные объёмы данных.

👉 @BackendPortal

Вот что нашёл: AITMPL — это огромная open-source-коллекция компонентов для Claude Code: skills, агенты, команды, хуки, MCP, плагины, циклы, настройки и многое другое — всё аккуратно распределено по категориям.

👉 @BackendPortal

Учебный проект бэкенд системы управления рестораном на Go

Проект построен с упором на продакшен-подходы и хорошо задокументирован с помощью swaggo/swag.
В бэкенде реализованы событийно-ориентированная архитектура, Redis Streams, фоновые воркеры и Outbox Pattern для надёжной доставки email. Для защиты от повторной обработки используются распределённые блокировки и идемпотентные сценарии оплаты и возвратов.

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

Для поиска используется PostgreSQL Full Text Search с взвешенным tsvector, а производительность запросов оптимизируется с помощью индексов и EXPLAIN ANALYZE.

https://github.com/AboloreDev/geritcht-restaurant

👉 @BackendPortal

Нужно заглянуть внутрь образа контейнера, не запуская его?

Один из самых практичных способов:

docker create --name tmp my-image
docker export tmp | tar -C rootfs -xf -

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

Но если вам нужно извлечь образ контейнера в полноценный rootfs, который корректно сохранит все права доступа, владельцев файлов и расширенные атрибуты (xattrs), например, capabilities, sticky bits и т. д. — всё быстро становится гораздо сложнее.

Вот несколько практических способов и описал все подводные камни здесь: https://labs.iximiuz.com/tutorials/extracting-container-image-filesystem

👉 @BackendPortal

Сис. дизайн: Балансировщик нагрузки

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

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

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

- Если сервер 1 выйдет из строя, весь трафик будет перенаправлен на сервер 2. Это не позволит сайту стать недоступным.
- Если трафик сайта резко вырастет и двух серверов окажется недостаточно, балансировщик нагрузки позволит корректно решить эту проблему. В пул можно добавить дополнительные веб-серверы, после чего балансировщик автоматически начнёт направлять запросы и на них.

Вертикальное и горизонтальное масштабирование

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

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

При низкой нагрузке вертикальное масштабирование может быть хорошим вариантом, а его главное преимущество — простота.

Ограничения вертикального масштабирования

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

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

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

Эта проблема решается с помощью горизонтального масштабирования и балансировщика нагрузки.

👉 @BackendPortal

Собеседования по системному дизайну — это на 80% вопросы и на 20% диаграммы.

Чем лучше вы уточняете требования, тем лучше получается архитектура.

Слабый кандидат слышит:

«Спроектируйте систему уведомлений».

И сразу рисует:

API → очередь → воркер → база данных

Сильный кандидат сначала задаёт вопросы:

1. Сколько пользователей?
2. Какие типы уведомлений нужны?
3. Email, SMS, push-уведомления или всё сразу?
4. Доставка должна быть в реальном времени или с задержкой?
5. Допустима ли повторная доставка одного уведомления?
6. Нужно ли сохранять порядок доставки?
7. Что происходит при сбое провайдера?
8. Могут ли пользователи настраивать свои предпочтения?
9. Как долго нужно хранить историю доставки?

Эти вопросы и есть проектирование.

Всё остальное — лишь визуализация того, что вы выяснили.

Каждый ответ меняет архитектуру:

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

Диаграмма не должна строиться по памяти.

Она должна вытекать из выявленных ограничений.

На собеседовании по системному дизайну хорошие вопросы дают три преимущества:

→ уменьшают неопределённость;
→ выявляют компромиссы;
→ показывают ход вашего мышления.

Сначала требования.

Потом архитектура.

👉 @BackendPortal

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

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

👉 @BackendPortal

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

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

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

👉 @BackendPortal

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

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

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

👉 @BackendPortal