15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Здесь разбирают, как работают key-value базы данных и как можно сделать свою с нуля. (на Go)
👉 @BackendPortal
Парень реализовал свой аналог Redis на Go 👍
Фичи:
- Асинхронный (на epoll) и синхронный (на goroutine) серверы
- Полная поддержка протокола RESP
- Базовые команды: PING, SET, GET, DEL, TTL
- Готов к запуску в Docker для удобного деплоя
👉 @BackendPortal
В проекте используется Redis, и нужно часто его просматривать и управлять. Многие инструменты либо устарели, либо перегружены.
Недавно нашёл Tiny RDM — лёгкое и удобное десктоп-приложение для работы с Redis. Построено на WebView2, не тянет встроенный браузер, интерфейс чистый и понятный. Все операции с ключами: добавление, удаление, просмотр, редактирование
Поддерживает SSH, SSL, HTTP, SOCKS5, встроен редактор Monaco, как в VS Code. Есть разные форматы просмотра данных, мониторинг команд в реальном времени и slow logs для анализа производительности.
Работает на Windows, macOS и Linux, есть светлая и тёмная тема.
👉 @BackendPortal
У больших компаний десятки сервисов, сотни сотрудников и свои правила безопасности. Каждый новый аккаунт в облаке — это лишний пароль, риск и головная боль для IT-отдела. Чтобы от этого избавиться, мы реализовали федеративный вход в MWS Cloud Platform.
В новой статье рассказываем:
⏺️как работает федерация в MWS и причём здесь SSO;
⏺️почему мы выбрали модель syncless, а не синхронизацию пользователей;
⏺️как маппинг атрибутов позволяет гибко настраивать права доступа пользователей в MWS Cloud Platform;
⏺️зачем это бизнесу.
Федерация превращает облако в естественное продолжение вашей IT-инфраструктуры без лишних логинов и с полным доверием к вашему IdP.
⏩Читать статью
Используем insteadOf в Git для Замены HTTPS-адресов на SSH
При работе с Git-репозиториями вы часто сталкиваетесь с URL-адресами в формате HTTPS, особенно при клонировании из GitHub, GitLab или других хостинг-провайдеров. Однако, если вы предпочитаете использовать SSH для аутентификации (что часто удобнее с аутентификацией по ключам), ручное изменение URL-адресов может быть утомительным. Кроме того, это может быть ещё сложнее при работе с субмодулями.
Конфигурационная опция Git insteadOf предлагает элегантное решение, автоматически переписывая URL-адреса «на лету»:
git config --global url."git@github.com:".insteadOf "https://github.com/"
git config --global url."git@gitlab.com:".insteadOf "https://gitlab.com/"
git config --global url."git@bitbucket.org:".insteadOf "https://bitbucket.org/"
git config --global url."git@github.com:username/".insteadOf "https://github.com/username/"
# Следующая команда
git clone https://github.com/user/repo.git
# Станет эквивалентной
git clone git@github.com:user/repo.git
git config --global url."https://<token>@github.com/".insteadOf "https://github.com/"
Нашёл классную альтернативу Postman и Insomnia — Yaak.
Это лёгкий и быстрый инструмент для тестирования API, написанный на Tauri, Rust и React. Работает офлайн, не сливает данные и поддерживает REST, GraphQL, gRPC, WebSocket и другие протоколы.
Можно импортировать коллекции из Postman, использовать переменные окружения, хранить ключи в системном хранилище и даже кастомизировать интерфейс.
Репозиторий: github.com/mountain-loop/yaak
👉 @BackendPortal
Вышел свежий эпизод шоу Backend Engineering, посвящённый теме HTTP Graceful Shutdown (корректному завершению соединений на сервере.)
Автор объясняет, почему иногда бэкенд должен закрывать соединения: чтобы избежать сбоев, ограничить недобросовестных клиентов или освободить системные ресурсы. В выпуске разбираются механизмы плавного завершения работы соединений в HTTP/1.1 (через заголовок Connection) и HTTP/2 (через фрейм GOAWAY), а также обсуждается, сколько это стоит с точки зрения производительности и архитектуры.
Кратко по эпизоду:
Зачем вообще завершать соединение
Как работает graceful shutdown в HTTP/1.1
Издержки HTTP/2
Что делает фрейм GOAWAY
Выводы и лучшие практики
В распределённых системах любая часть может отказать в любой момент.
Как при этом вообще общаться между компонентами, если всё вокруг ненадёжно? Это реально непросто.
Классический пример такой ситуации — проблема двух генералов. Она отлично иллюстрирует трудности коммуникации через ненадёжные каналы.
Представь: генерал А и генерал B стоят в разных лагерях со своими армиями и должны согласовать время атаки, передавая сообщения только пешими гонцами.
А отправляет сообщение «атакуем на рассвете!», но ответа не получает. Что произошло — неизвестно. Гонец мог погибнуть по пути к B, или B получил послание, но ответный гонец пропал на обратной дороге.
Эта задача доказано неразрешима. Звучит как байка, но суть та же самая, когда серверы в дата-центре пытаются договориться между собой по TCP.
Даже если узлов всего два, и один не получил ответ, причин может быть куча — от сбоя сети до зависшего процесса.
И вот это одно из главных умений инженера по распределённым системам: строить надёжные системы поверх ненадёжных компонентов.
👉 @BackendPortal
Вот 20 проверенных техник, которые я регулярно использую для оптимизации SQL-запросов: 😊
• Грамотно используйте индексы:
Индексируйте критически важные столбцы, используемые в WHERE, JOIN, ORDER BY и GROUP BY.
• Избегайте SELECT *:
Выбирайте только необходимые столбцы, чтобы сократить объём передаваемых данных и время обработки.
• Реализуйте пагинацию корректно:
Используйте OFFSET и FETCH NEXT или пагинацию методом поиска (seek method) для эффективного постраничного вывода.
• Ограничивайте количество строк как можно раньше:
Применяйте фильтрацию на ранних этапах, чтобы максимально сократить размер выборки.
• Избегайте функций в WHERE:
Функции над столбцами блокируют использование индексов — переписывайте условия, используя «сырые» столбцы.
• Упрощайте JOIN:
Минимизируйте количество соединений и избегайте избыточных JOIN-ов.
• Выбирайте правильные типы JOIN:
Используйте INNER JOIN, LEFT JOIN или EXISTS там, где это уместно, чтобы избежать лишней обработки данных.
• Используйте корректные типы данных:
Сопоставляйте типы данных в JOIN и WHERE, чтобы обеспечить эффективное использование индексов.
• Запрашивайте только изменённые данные:
Реализуйте инкрементальную обработку, а не полный повторный запрос таблиц.
• Группируйте операции:
Пакетная вставка, обновление или удаление снижают накладные расходы на транзакции.
• Исключайте избыточные подзапросы:
Используйте JOIN или CTE вместо повторяющихся подзапросов.
• Используйте EXISTS вместо IN:
EXISTS часто работает быстрее, чем IN, особенно на больших объёмах данных.
• Нормализуйте с умом:
Балансируйте между нормализацией и денормализацией в производительно критичных запросах.
• Применяйте материализованные представления:
Предварительно рассчитывайте сложные агрегации и запросы для ускорения чтения.
• Анализируйте планы выполнения:
Регулярно проверяйте execution plan, чтобы находить и устранять ресурсоёмкие операции.
• Избегайте подстановок с начальным %:
LIKE '%abc' не использует индексы эффективно.
• Делайте транзакции короткими:
Сокращайте время выполнения транзакций, чтобы уменьшить блокировки и конфликты.
• Регулярно обновляйте статистику:
Актуальные статистики обеспечивают точное планирование запросов СУБД.
• Используйте подсказки (query hints) с осторожностью:
Применяйте только после тестирования и при необходимости конкретной оптимизации.
• Постоянно отслеживайте и настраивайте:
Регулярно анализируйте производительность запросов и проактивно оптимизируйте медленные запросы.
Есть опенсорсный проект под названием Redka. Его цель — переосмыслить основные части Redis, реализовав их на SQL (SQLite/PostgreSQL), при этом сохранив совместимость с API Redis (протокол RESP).
Идея вроде нравится людям, но я не вижу, чтобы кто-то реально этим пользовался.
Лучшая альтернатива Postman ❓
Apidog — мощный инструмент для работы с API.
✓ Создавай, проектируй и документируй эндпоинты за пару минут
✓ Мокай данные и запускай тесты на лету
✓ Подключай и проверяй ИИ вроде ChatGPT
Доступен в вебе и как приложение, есть бесплатный план.
https://apidog.com/
👉 @BackendPortal
⭐️ Road to Highload: видеопроект о проектировании архитектуры высоконагруженных систем
Инженеры Яндекс 360 накопили значительный опыт в проектировании и разработке систем, которыми ежедневно пользуются больше 95 миллионов человек ежемесячно.
В этом видеопроекте разработчики на практических примерах рассказывают, как создают архитектуру систем, которые держат 1 000 000 RPS и хранят петабайты мета-данных.
В выпусках обсуждаем:
🎙 Серия 1. Функциональные и нефункциональные требования. Как сбор требований помогает создавать надёжные и масштабируемые решения
🎙 Серия 2. Надёжный API. Принципы проектирования API, которые помогут сделать его консистентным, предсказуемым и поддерживаемым
🎙 Серия 3. Крупноблочная архитектура: карта вашей системы. Как выглядит модель на примере Яндекс Календаря и как ребята применяют её для эффективной коммуникации с различными командами разработки
🎙Серия 4. Практика: Рост баз данных: от единиц запросов к тысячам. Как правильно организовать работу с БД, чтобы система оставалась стабильной и эффективной
🎙 Серия 5. Практика. Взаимодействие со смежными системами. Типичные сложности, с которыми сталкиваются команды при интеграции с внешними сервисами, и как их предотвратить или минимизировать
Создаётся крупнейшая база реальных DevOps-проектов и ресурсов для тех, кто хочет перейти от теории к практике. 🥺
В ней собраны живые примеры AWS-проектов с Terraform и GitHub Actions, Docker-конфиги, мультиоблачные решения на GCP и Azure, а также полноценные деплои на Kubernetes.
Это то, чего многим не хватало в начале пути — практики, которую можно запустить, изучить и доработать под себя. База уже наполняется рабочими проектами, которые помогают понять, как DevOps устроен в реальном мире.
Кто хочет внести вклад: https://github.com/akhileshmishrabiz
👉 @BackendPortal
PostgreSQL использует ленивое «swizzling» указателей (lazy pointer swizzling), чтобы ускорить доступ к буферу и держать данные на диске и в памяти синхронизированными без лишних преобразований. Вот как это работает.
Когда PostgreSQL хранит структуры данных, например страницы B-tree индекса, на диске нельзя использовать обычные указатели из оперативки → адреса на диске и в памяти вообще из разных миров. Но как только данные попадают в память, хочется быстро ходить по структуре через указатели, а не через медленные косвенные ссылки.
На диске PostgreSQL хранит ссылки в виде номеров блоков и смещений. Когда страница читается в общий буферный пул, эти логические ссылки остаются как есть → и вот тут начинается интересное.
Буферные страницы
→ Каждая страница в памяти идентифицируется с помощью структуры BufferTag (в ней указаны база, таблица и номер блока).
→ В памяти PostgreSQL держит массив дескрипторов буферов.
→ Когда нужно получить доступ к странице, код идет через менеджер буферов, который по номеру блока находит реальное местоположение страницы в памяти.
→ Это и есть ленивое swizzling — преобразование адреса выполняется не заранее, а при каждом обращении.
Пример структуры BufferTag из исходников PostgreSQL:
typedef struct
{
Oid spcOid; /* tablespace */
Oid dbOid; /* database */
Oid relNumber; /* relation (table or index) */
ForkNumber forkNum;/* main, fsm, vm, init forks */
BlockNumber blockNum; /* block number within the relation */
} BufferTag;
Многим формат инструкций WASM напоминает LISP. И тут собственно ничего удивительного: под LISP и лиспоподобные языки очень удобно писать разные парсеры. Не случайно Брендон Айк - создатель JavaScript, изначально хотел создать язык для браузера на основе Лиспа, но его начальство настаивало на языке, похожем на Java (так как в то время Java была на хайпе) . Поэтому мы и получили то, что получили.
👉 @BackendPortal
30 октября приглашаем на MWS Cloud Day: первую технологическую конференцию MWS про облака.
Вас ждёт:
• Премьера MWS Cloud Platform — нового облака собственной разработки от MWS
• Доклады о технологиях и архитектурных решениях под капотом нового облака
• Выставочная зона с демостендами и кастомным мерчом
• Панельная дискуссия с ведущими экспертами отрасли
• Афтепати и неформальное общение вечером
📍Где и когда:
30 октября
Москва, кинотеатр «Художественный» + онлайн
Участие бесплатное, но нужно зарегистрироваться
Лёгкий сервер, мониторинг Docker и система алертов
https://github.com/henrygd/beszel/
👉 @BackendPortal
На одном собеседовании по системному дизайну я использовал Kafka.
На другом — Redis.
На третьем — S3.
Но на всех собеседованиях я использовал базы данных.
Базы данных — это основа любого дизайна, независимо от масштаба, стека или домена.
Если ты понимаешь, как данные хранятся, запрашиваются, индексируются, реплицируются и шардируются — ты уже понимаешь процентов 70 системного дизайна.
Не отвлекайся на блестящие новые компоненты. Очереди, кэши и оркестраторы приходят и уходят.
А базы данных остаются.
Реляционные, NoSQL, time-series, векторные — паттерны меняются, но принципы одни и те же:
- Пути чтения и записи
- Индексация и кэширование
- Транзакции и уровни изоляции
- Репликация и партиционирование
Пойми, как движутся данные и ты увидишь, как всё остальное в системе связывается между собой.
Изучи базы данных глубоко.
Всё остальное просто оптимизация.
👉 @BackendPortal
Бэкэнд Go с открытым исходным кодом, подписками в реальном времени, встроенной базой данных, пользовательским интерфейсом администратора
https://github.com/pocketbase/pocketbase/
👉 @BackendPortal
Как пишет автор: «...эта статья лишь поверхностно касается темы кеширования...». И правда, кеширование — тема интересная и глубокая.
Советую почитать эту интерактивную статью, а потом кейсы в конце. Они хорошо показывают, как кеширование применяется на практике.
planetscale.com/blog/caching
👉 @BackendPortal
В это репо собраны клоны 100+ популярных приложений вроде Netflix, Airbnb, Spotify, Amazon и других — вместе с исходниками и туториалами.
Отличный способ учиться, повторяя реальные проекты, и прокачивать скилл разработки через практику :)
👉 @BackendPortal
На GitHub появился gocraft от telman03 — инструмент, который генерирует полноценный Go-бэкенд с уже настроенной авторизацией, базой данных, gRPC, Docker, Swagger и мониторингом. Проект создан, чтобы ускорить старт разработки и избавить от рутины при создании сервисов.
gocraft позволяет собрать структуру проекта под себя: выбрать фреймворк (Gin, Echo или Fiber), нужные БД (PostgreSQL, MySQL, SQLite, MongoDB, Redis) и сразу получить рабочее окружение. Безопасность тоже продумана — есть JWT, валидация, защита от SQL-инъекций и rate limiting.
Проект поддерживает REST, WebSocket и gRPC, умеет генерировать Swagger-документацию и контейнеризируется через Docker. Всё с открытым кодом и MIT-лицензией.
Репозиторий: github.com/telman03/gocraft
👉 @BackendPortal
Почему Google хранит миллиарды строк кода в одном репозитории
В Google используется монорепозиторий — единый источник правды для десятков тысяч разработчиков по всему миру. В нём лежит около 95% всего исходного кода компании. Исключения — только проекты вроде Chrome и Android, у которых свои репозитории.
Изначально Google пользовались CVS, потом перешли на Perforce, а позже заменили его на собственную систему Piper. По данным 2016 года, репозиторий содержал более 2 миллиардов строк кода и получал около 40 000 коммитов в день от более чем 10 000 инженеров.
Разработка ведётся по trunk-based модели, то есть все изменения интегрируются прямо в основную ветку после ревью. Такой подход помогает избежать адского merge hell и держит код синхронизированным.
Перед коммитом система Tricorder автоматически проверяет код и выдаёт первый фидбэк. А для ручного ревью используется инструмент Critique.
Для массовых рефакторингов и оптимизаций инженеры применяют Rosie — систему, которая разбивает огромные изменения на маленькие пачки и рассылает их на ревью владельцам соответствующих частей кода.
Преимущества такого подхода:
единая версия для всего кода
простое и безопасное шаринг кода между командами
упрощённое управление зависимостями
атомарные коммиты
возможность делать масштабные рефакторинги
прозрачность и гибкость в распределении ответственности
высокая видимость кода и сотрудничество между командами
нужно разрабатывать и масштабировать собственные инструменты, следить за “health” кодовой базы и бороться с её растущей сложностью — например, с неочевидными зависимостями.
Эволюция менеджера буферов в PostgreSQL
Буферный менеджер PostgreSQL отвечает за кэширование 8KB страниц с диска в общем пуле памяти. Для поиска используется хеш-таблица (через BufferTag → buffer ID), а для вытеснения страниц — алгоритм clock-sweep.
Ранние версии делались с прицелом на простоту в многопроцессной архитектуре, но страдали от грубой системы блокировок — один глобальный лок быстро становился узким местом под нагрузкой.
За 30 лет модель конкурентного доступа сильно изменилась:
от глобального мьютекса → к локам на каждый буфер → затем к разделённым (partitioned) локам → и, наконец, к атомарным операциям, которые позволяют большинству структур работать вообще без блокировок.
Это кардинально снизило конкуренцию за ресурсы и дало PostgreSQL отличную масштабируемость под OLTP-нагрузками, при этом сохранив надёжность при доступе к shared memory.
Философия дизайна проста:
- держать локи как можно меньше по времени
-абстрагировать различия железа через атомики
- устранять реальные bottleneck’и с помощью профилирования и точечных патчей
Отличный блогпост, показывающий хронологию этих изменений и ключевые коммиты, которые сделали PostgreSQL тем, что он есть сегодня
👉 @BackendPortal
👨💻 Продуктивный вайб-кодинг
AI-ассистенты уже в каждой IDE, но на реальных бэкенд-задачах они часто не понимают контекст проекта и генерируют код, который приходится часами исправлять.
Павел Федотовский, руководитель разработки low-code решений в Яндекс Go, делится в своей статье системным подходом, как превратить AI в действительно полезный инструмент, а не просто модную игрушку.
Что внутри:
🔹 Как с помощью метапромптинга научить модель следовать вашим правилам код-ревью.
🔹 Способ заставить AI самому вести и постоянно обновлять документацию по проекту.
🔹 Модель «Архитектор-Исполнитель» для написания целых сервисов с нуля.
Логичный, инженерный подход к работе с LLM. Рекомендуем.
➡️ Прочитать статью можно здесь
В PostgreSQL есть два способа репликации: физическая и логическая.
Обе крутые, но с разными компромиссами.
Физическая репликация передаёт на реплики весь WAL, создавая побайтовую копию основного узла. Это значит, что нагрузка на CPU у мастера минимальная, но при этом она работает только между одинаковыми версиями PostgreSQL (и даже некоторые версии расширений и glibc должны совпадать). Кросс-архитектурной репликации тоже нет.
Такой подход отлично подходит для схем "primary–replica" с высокой доступностью, но не годится для апгрейдов или миграции на другие платформы.
Логическая репликация работает на уровне строк. Она не делает поблочное зеркало данных, поэтому способна работать между всеми основными версиями PostgreSQL 10+, где она появилась.
Она гибче, но не волшебная таблетка для миграций. Логическая репликация не передаёт DDL и последовательности, так что часть работы придётся делать вручную. При больших объёмах данных (например, 1 ТБ и больше) она может быть медленной и просаживать производительность, поэтому процесс нужно тщательно планировать.
Что выбрать? Как обычно = зависит от ситуации. Иногда логичнее комбинировать их с инструментами вроде pg_dump.
👉 @BackendPortal
Узнайте все о протоколе HTTP : https://http.dev/
👉 @BackendPortal
Ты думаешь, что тебе это не нужно ‼️
🟣 Ты же не разработчик, твоя зона — это бизнес и пользователи.
Но правда в том, что технические скиллы дают продакту другой уровень силы:
⚫️быстрее проверять гипотезы
⚫️собирать прототипы без ожидания команды
⚫️понимать ограничения и возможности технологий
⚫️разговаривать с разработчиками на одном языке.
В итоге меньше зависимости, больше скорости и уверенности в продукте.
В канале Продукт и рост Яны Доценко мы разбираем инструменты, которые реально работают:
➡️от AI-билдеров до no-code и сетапов, с которыми можно запускать фичи и продукты самому.
Подписывайся, тут ты станешь настоящим фуллстек-боссом:
/channel/+J-Wtd0vQTXYxNjMy
Supabase теперь поддерживает очереди!
Помимо базы, аутентификации, хранилища и edge-функций, в Supabase появилась поддержка очередей, работающих на базе расширения pgmq.
Есть даже удобный интерфейс для их управления.
А если добавить cron и edge functions, получится мощная и масштабируемая система воркфлоу прямо внутри Supabase.
👉 @BackendPortal
TRUNCATE — это DDL.
У каждой таблицы и всех её индексов есть указатели на файлы на диске.
TRUNCATE просто сбрасывает эти указатели, создавая "пустые" файлы.
Чтобы операция была атомарной, TRUNCATE берёт эксклюзивную блокировку таблицы, блокируя все чтения и записи на время переназначения файлов.
Сами файлы потом удаляются отдельно — не обязательно синхронно.
DELETE FROM позволяет выполнять параллельные операции, но работает гораздо медленнее, и все изменения при этом логируются в WAL.
Оба подхода полезны — важно понимать, как они работают, чтобы грамотно проектировать приложение и не ловить тормоза.
Один из классных приёмов → разбивать таблицы по годам и просто truncate'ить нужный партишн, чтобы мгновенно удалить данные за целый год.
👉 @BackendPortal