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

https://medium.com/@saad.ahmed1926q/kv-cache-explained-intuitively-2b425a36dfc7

👉 @BackendPortal

Запомни: Монолит ≠ Модульный монолит ≠ Микросервисы

Многие команды думают, что путь выглядит так:
Монолит → Микросервисы

Но между ними есть важный этап, который многие пропускают... Модульный монолит.

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

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

Простая шпаргалка 👇
✅ Монолит = одно приложение
✅ Модульный монолит = одно приложение, много модулей
✅ Микросервисы = множество независимых приложений

Когда использовать каждый подход?

🔹 Монолит
стартапы и MVP;
небольшие команды;
быстрая разработка;
простое развёртывание.

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

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

Самое распространённое заблуждение. Микросервисы не становятся автоматически лучшим выбором.
Они привносят распределённые транзакции, сетевые задержки, обнаружение сервисов (service discovery), наблюдаемость (observability), версионирование, пайплайны развёртывания и дополнительные операционные издержки.

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

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

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

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

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

👉 @BackendPortal

Fable 5 монстр: чуваки создали невероятно лёгкий бэкенд, совместимый с Supabase, который работает как единый бинарный файл размером всего около 57 МБ!

Да, внутри уже есть полноценный PostgreSQL с RLS (Row-Level Security), а также встроенные Auth, Storage и Realtime.

https://tinbase.vercel.app/

👉 @BackendPortal

Инсайд: Я думал, что довольно хорошо знаю PostgreSQL, пока не наткнулся на это.

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

* очереди;
* cron-задачи;
* Redis;
* MongoDB;
* векторные базы данных;
* журналы аудита;
* и даже некоторые сценарии использования Kafka.

Я не говорю, что нужно заменить Postgres'ом каждый инструмент в вашем стеке.

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

Определённо стоит прочитать, если вы разрабатываете backend-системы. Этот материал заставил меня пересмотреть многие свои представления.

👉 @BackendPortal

Немного разобрался с тем, как работают блокировки в 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