Один из способов не утонуть в сложности при проектировании системы — использовать определённую структуру / ментальную модель. Вот простая модель, которой я пользуюсь…

Представь любую систему как состоящую из двух отдельных путей: read path и write path. Твоя база данных или слой хранения находится в центре, а у каждого пути — свой набор проблем и свой инструментарий для их решения.

Write path — это про надёжность (durability) и пропускную способность (throughput). Как правило, ты выбираешь из одного и того же набора инструментов: message queue для сглаживания пиков нагрузки, write-ahead logging для обеспечения надёжности, batching для снижения I/O и асинхронная обработка, чтобы не перегружать критический путь.

Read path — это про задержки (latency) и масштабируемость. И здесь тоже есть стандартный набор: кэширование на разных уровнях (CDN, уровень приложения, уровень запросов), read-реплики для разгрузки primary, денормализация или предвычисление тяжёлых запросов, а также пагинация или cursor-based обход, чтобы избежать полного сканирования.

Когда начинаешь воспринимать это как две отдельные задачи, ты перестаёшь «проектировать систему» целиком и начинаешь отвечать на два более простых вопроса: что нужно write path? что нужно read path? А затем связываешь их через слой хранения.

Этот «фреймворк» (если его так можно назвать) полезен не только в обсуждениях, но и помогает лучше понимать продакшн-системы — особенно когда ты разбираешься в существующей архитектуре, оптимизируешь текущий флоу, дебажишь всплески latency или планируешь масштабирование.

Надеюсь, это поможет.

👉 @BackendPortal

URI vs URN vs URL — в чём разница?

Если представить библиотеку, книгу можно идентифицировать тремя способами:

- Адрес библиотеки и расположение книги на полке (URL)
- ISBN книги (URN)
- Любым из этих способов (URI)

Соответственно, есть три типа идентификаторов:

URI (Uniform Resource Identifier) — это общее, родительское понятие. Любая строка, которая идентифицирует ресурс. И URL, и URN являются частными случаями URI.

URL (Uniform Resource Locator) — указывает, как получить доступ к ресурсу.
Например: [https://linkedin.com/in/yourprofile]
Это аналог физического адреса — он говорит, куда именно идти.

URN (Uniform Resource Name) — это уникальное имя ресурса, которое остаётся неизменным, даже если ресурс перемещён или недоступен.
Пример: urn:isbn:0-486-27557-4
Можно сравнить с номером социального страхования — он идентифицирует объект, но не говорит, где его найти.

👉 @BackendPortal

Писать код сейчас легко, а вот тестировать — сложно.

Давайте посмотрим, где именно находятся разные виды тестов и какую роль они играют. ⬇️⬇️⬇️

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

Решение: http-status-codes

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

👉 @BackendPortal

30 вопросов по Docker, которые задают на собеседованиях в DevOps.

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

👉 @BackendPortal

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

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

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

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

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

Движок MySQL InnoDB следует этому подходу.

Косвенный первичный индекс (Heap + вторичный индекс)

В этом подходе первичный индекс указывает на промежуточный идентификатор (например, row ID), который уже ссылается на фактическое расположение данных. Сами данные хранятся в неупорядоченной куче (heap). Это позволяет отделить хранение данных от организации индексов.

PostgreSQL предпочитает этот подход.

Надеюсь, это было полезно.

👉 @BackendPortal

Есть два способа реализовать real-time коллаборацию — либо всё гонять через центральный сервер, либо использовать P2P mesh. Представим совместный canvas, как в Figma, Canva или Miro, с 10 пользователями.

Если проксировать каждое движение курсора через сервер, 10 пользователей генерируют по 60 обновлений указателя в секунду — это 600 сообщений, приходящих на сервер, который затем рассылает их 9 получателям. В итоге получается 5 400 сообщений в секунду на одну сессию — только для трекинга мыши.

Альтернатива — P2P mesh: каждый клиент напрямую подключается ко всем остальным, и сервер вообще не участвует в передаче этих высокочастотных пакетов.

Но у mesh-подхода есть своя проблема — количество соединений растёт по формуле n × (n - 1) / 2.
При 4 пользователях — 6 соединений.
При 10 — уже 45.
При 20 — 190.

То есть каждый браузер держит (n - 1) одновременных WebRTC-соединений. Нагрузка на сервер падает до нуля, но сложность на клиенте растёт квадратично.

Когда же mesh имеет смысл?

Используй mesh-топологию, когда данные:

- высокочастотные
- некритичные (low-stakes)
- чувствительны к задержкам

Например: позиции курсоров, live-выделения, штрихи рисования. Потеря одного обновления не страшна — следующее придёт через ~16 мс. В этом случае сервер реально не даёт дополнительной ценности.

Не используй mesh для важных операций:

- сохранение документа
- изменения прав доступа
- разрешение конфликтов

Такие вещи должны идти через сервер.

Хороший способ мыслить о mesh — это как о способе вынести определённый класс трафика с сервера.

Важно запомнить: не все real-time данные одинаковы.

Позиции курсора и зафиксированное состояние (committed state) имеют совершенно разные требования. Если обрабатывать их одинаково — например, гонять всё через сервер — ты сам создаёшь bottleneck.

Раздели трафик по допустимым потерям и задержкам — и архитектура станет очевидной.

👉 @BackendPortal

Что такое REST и какие у него ограничения ?

REST (Representational State Transfer) — это архитектурный стиль для построения сетевых приложений, чаще всего используемый при разработке web API. Он был предложен Roy Fielding в его докторской диссертации в 2000 году.

REST основан на 6 ключевых ограничениях:

1. Uniform Interface (Единый интерфейс)
Стандартизированный способ взаимодействия с ресурсами (обычно через HTTP: GET, POST, PUT, DELETE).

2. Client-Server (Клиент–сервер)
Разделение ответственности между клиентом (UI) и сервером (данные и логика).

3. Stateless (Без сохранения состояния)
Каждый запрос должен содержать всю информацию, необходимую для его обработки. Сервер не хранит состояние клиента между запросами.

4. Cacheable (Кэшируемость)
Ответы должны явно указывать, можно ли их кэшировать, чтобы повысить производительность.

5. Layered System (Слоистая архитектура)
Компоненты взаимодействуют только со своим ближайшим слоем и не знают о всей системе целиком.

6. Code-on-Demand (по желанию)
Сервер может отправлять исполняемый код клиенту (например, JavaScript), расширяя его функциональность.

👉 @BackendPortal

Когда сетевое разделение приводит к сценарию split-brain, большинство систем пытаются автоматически устранить его с помощью протоколов консенсуса. Vitess идёт другим путём...

Он намеренно придерживается консервативного подхода к автоматическим действиям.

У Vitess есть компонент автоматического обнаружения и восстановления сбоев под названием VTOrc. Он выполняет автоматический failover, но только тогда, когда это можно сделать безопасно в рамках настроенной политики надёжности (durability policy). Если он не может гарантировать безопасное переключение, он не будет ничего предпринимать.

Причина в том, какие именно цели вы оптимизируете.

Vitess использует полусинхронную репликацию (semi-synchronous replication) с fallback на асинхронную репликацию. Это означает, что primary будет приостанавливать выполнение (stall), вместо того чтобы молча принимать записи, которые не были подтверждены хотя бы одной репликой.

Этот компромисс сделан осознанно: простой (stall) можно пережить, расхождение данных — нет.

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

Когда VTOrc не может подтвердить, что способен выполнить failover без потери данных (lossless), он откажется повышать новый primary, если вы явно не переопределите проверки безопасности. Запросы, зависящие от этого primary, могут завершаться с ошибкой или зависать, но Vitess не примет решение, которое может привести к повреждению данных.

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

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

Не каждый отказ (всегда) требует автоматического исправления.

👉 @BackendPortal

Эволюция протокола HTTP

👉 @BackendPortal

Пакет io — это ключевая часть стандартной библиотеки Go. Портировать его на C оказалось довольно интересной задачей.

Автору пришлось разобраться, как в C реализовать срезы (slices), множественные возвращаемые значения, обработку ошибок и интерфейсы. Но в итоге всё получилось довольно неплохо!

Читать фулл статью

👉 @BackendPortal

После тысячи видео "Стань Python-разработчиком с 0 до PRO" нашли видео для джунов, которые уже знают базу и не хотят опять слушать про print("Hello, World!")

Если уже знаешь синтаксис и основные конструкции в питоне, но застрял на уровне джуна, то видео точно будет полезно. Как мы поняли, это первая часть. В ней про Pydantic, ООП и декораторы настолько понятно, насколько это вообще возможно. К концу второй части обещают подтянуть зрителя до миддла — надо будет проверить 👍

👉 @BackendPortal

Microsoft открыла исходники обучающих материалов по Rust для уровней beginner, advanced и expert 🦀

👉 @BackendPortal

🦀 Rust: основы Zero Knowledge.

Этот подробный разбор объясняет, почему полиномы являются ключевой структурой данных в ZK, как используются конечные поля и почему лемма Шварца—Циппеля делает верификацию настолько эффективной — всё это с исполняемыми примерами кода на Rust.

https://rustarians.com/polynomials-in-zk-snarks/

👉 @BackendPortal

А что если бы можно было запускать Postgres как один файл и при этом использовать всё лучшее из SQLite?

Разработчик представил pg-micro — экспериментальный проект, который пытается это реализовать.

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

Как это работает: используется нативный парсер Postgres для разбора запроса, после чего он компилируется в AST от Turso. Затем этот AST компилируется в байткод, и дальше всё исполняется нативно — так же, как в SQLite. Благодаря этому решение можно запускать практически в любом окружении.

Исторически между Postgres и SQLite есть функциональный разрыв. Но Turso активно его сокращает: такие вещи, как MVCC и строгая развитая система типов, уже реализованы. Также есть PR’ы для lateral join’ов и других возможностей, что в теории позволяет свести разрыв почти к нулю.

Что это даёт на практике?
Можно представить, например, примитив наподобие Durable Objects от Cloudflare, но с интерфейсом Postgres.
Или использовать паттерн локальных баз данных для агентов, как в SQLite — полностью эфемерных и бесплатных, но с интерфейсом Postgres.
Или выполнять удалённый Postgres на платформах вроде Vercel, но с плотностью, которую даёт Turso Cloud.

Пока что многое может не работать — проект экспериментальный. Но он развивается как open source, поэтому PR’ы приветствуются.

Старт: npx pg-micro

👉 @BackendPortal