Backend Portal | Программирование

Диграмма микросервисной архитектуры и связанных с ней паттернов 👉 @BackendPortal

Proxmox 9.1 теперь нативно поддерживает OCI-образы (Docker) Proxmox VE 9.1 теперь поддерживает OCI-контейнеры на базе LXC, использует ядро Linux 6.17 и содержит улучшения в области виртуализации, безопасности и сетевых функций Подробнее здесь 👉 @BackendPortal

В новой статье на Хабре Алексей Кременьков, бэкенд-разработчик в Яндекс 360, рассказывает о создании и эволюции сервиса динамического шардирования Sharpei для масштабирования PostgreSQL под нагрузкой в 300К+ RPS. Пошагово разберём, как: • Создали собственный инструмент для управления 700+ шардами PostgreSQL • Справились с пиковыми нагрузками при миграциях • Автоматизировали перенос пользователей между шардами и переехали в облако без даунтайма Сервис Sharpei позволил Яндекс Почте перейти к гибкому горизонтальному масштабированию, полностью автоматизировать управление шардами и добиться четырёх девяток отказоустойчивости. ↘️ Подробнее читайте на Хабре

С UUIDv7 в PostgreSQL 18 сортировка через ORDER BY теперь реально выдаёт записи в порядке их создания. 👉 @BackendPortal

12 рекомендаций по дизайну API для бэкенд-разработчиков (Их часто спрашивают на собеседованиях) 1. Понятные имена ресурсов

    
        ❌`GET /get-all-orders`  
✅`GET /orders`{}
    

2. Корректное использование HTTP-методов - POST /users — создать пользователя - GET /users/123 — получить пользователя - PUT /users/123 — заменить полностью - DELETE /users/123 — удалить 3. Идемпотентность Клиент отправляет:

    
        POST /payments
Idempotency-Key: abc-123{}
    

Если запрос повторится, сервер должен вернуть тот же результат, не создавая операцию заново. 4. Версионирование API Рекомендуемый вариант — в URL:

    
        GET /v1/products/42
GET /v2/products/42{}
    

5. Правильные статус-коды Если пользователь не найден:

    
        ❌ `200 OK { "error": "user not found" }`  
✅ `404 Not Found`{}
    

6. Пагинация Пример:

    
        GET /articles?page=2&limit=50{}
    

Ответ должен содержать элементы 51–100. 7. Фильтрация и сортировка Пример:

    
        GET /orders?status=shipped&sort=-created_at{}
    

8. Безопасность Использование JWT в заголовках:

    
        Authorization: Bearer <token>{}
    

9. Rate limiting Например: 100 запросов в минуту. После превышения — вернуть:

    
        429 Too Many Requests{}
    

10. Кэширование Запрос:

    
        GET /blog/posts/123{}
    

Ответ содержит:

    
        ETag: "abc"{}
    

Повторный запрос:

    
        If-None-Match: "abc"{}
    

Если не изменилось — 304 Not Modified. 11. Документация Используй: - Swagger UI - OpenAPI Разработчики должны видеть схемы, параметры и иметь возможность тестировать запросы. 12. Быть прагматичным Иногда лучше так:

    
        POST /auth/login{}
    

чем строго REST-подход:

    
        POST /sessions{}
    

Хороший API читается как логичная, предсказуемая система и экономит время всем, кто с ним работает. 👉 @BackendPortal

Хочешь избежать проблем, когда Cloudflare падает? Или когда La Liga блокирует твои страницы? Разработчик сделал open-source CLI, чтобы можно было легко отключать этот сервис в проектах за пару секунд.

    
        $ npx disable-cloudflare@latest{}
    

👉 @BackendPortal

Если честно, я всё чаще замечаю, что бэкенд-сообщество – невероятно разное. Здесь есть и те, кто только начинает разбираться в сервисах и базах, и те, кто уже пишет такие системы, которые держат на себе половину интернета. Но есть одна общая черта: хороших бэкендеров формирует не только практика, но и среда, в которой они находятся. Мы растём быстрее, когда видим, как мыслят другие разработчики: какие решения принимают, какие компромиссы выбирают, как подходят к сложным задачам. И иногда одна чужая история или разбор может дать гораздо больше, чем длинные учебники или курсы. Поэтому хочу поделиться небольшой папкой каналов, где собраны разработчики, которые по-разному мыслят, по-разному пишут и по-разному растут. Среди них есть те, кто ежедневно ковыряет продакшен, те, кто давно ушёл в архитектуру, и те, кто пробует силы в смежных направлениях. Если вы работаете с бэкендом, то скорее всего, найдёте там что-то ценное для себя: идеи, подходы, вдохновение или даже ответы на вопросы, которые давно крутились в голове. Хорошая среда делает нас сильнее 😎

25 золотых правил системного дизайна

1. Система с упором на чтение > Используй кэш (Redis/Memcached) для частых запросов вроде профилей пользователей 2. Низкая задержка > Используй кэш и CDN (Cloudflare), чтобы раздавать статику ближе к пользователю 3. Система с упором на запись > Используй Message Queue (Kafka) для буферизации большого объема записей (логи, аналитика) 4. ACID-требования > Используй SQL (PostgreSQL) для строгих транзакций вроде банковских операций 5. Неструктурированные данные > Используй NoSQL (MongoDB) для гибких схем, например каталогов товаров 6. Сложные медиа-ресурсы > Используй Blob Storage (AWS S3) для видео, изображений и больших файлов 7. Сложные предварительные расчёты > Используй Message Queue + Cache для асинхронной генерации контента (например ленты новостей) 8. Поиск при больших объемах данных > Используй Elasticsearch для полнотекстового поиска и автокомплита 9. Масштабирование SQL > Используй шардирование, чтобы разделить большие таблицы на несколько инстансов 10. Высокая доступность > Используй Load Balancer (NGINX) чтобы распределять трафик и избегать перегрузки 11. Глобальная доставка данных > Используй CDN для стабильного стриминга и раздачи контента по всему миру 12. Графовые данные > Используй Graph DB (Neo4j) для соцсетей, рекомендаций и связей между сущностями 13. Масштабирование компонентов > Используй горизонтальное масштабирование, а не просто апгрейд железа 14. Быстрые запросы к базе > Используй индексы на ключевых колонках вроде email или user_id 15. Пакетные задачи > Используй Batch Processing для отчётов, расчётов или периодических задач 16. Защита от злоупотреблений > Используй Rate Limiter, чтобы предотвращать DDoS и спам запросов к API 17. Доступ к микросервисам > Используй API Gateway для авторизации, маршрутизации и SSL-терминации 18. Единая точка отказа > Добавляй Redundancy (Active-Passive), чтобы сервис продолжал работать при сбоях 19. Отказоустойчивость данных > Используй репликацию (Master-Slave), чтобы данные не терялись при падении узлов 20. Реальное время > Используй WebSockets для чатов, лайв-обновлений, лайв-результатов 21. Обнаружение сбоев > Используй Heartbeat-пинг, чтобы проверять статус сервисов каждые несколько секунд 22. Целостность данных > Используй Checksums (MD5/SHA) чтобы проверить, что загруженные файлы не повреждены 23. Децентрализованное состояние > Используй Gossip Protocol, чтобы ноды обменивались статусами без центрального сервера 24. Эффективное кеширование > Используй Consistent Hashing, чтобы добавлять или убирать кэш-ноды без полного пересчёта ключей 25. Работа с геоданными > Используй Quadtree или Geohash для быстрых запросов вроде поиска ближайших водителей

👉 @BackendPortal

Случайные UUID заметно просаживают производительность базы Ты перешел с integer ID (1, 2, 3…) на UUID (a1b2-3c4d-…) ради безопасности или распределенной генерации. И вдруг вставки стали медленнее. Иногда намного. Причина простая - фрагментация индекса. Большинство индексов в базах данных это B-деревья (сбалансированные сортированные структуры). Физическое расположение данных в индексе реально важно. Последовательные ID Когда ты вставляешь последовательные целые числа (1, 2, 3), новые записи всегда попадают в правую страницу листа индекса. Все максимально предсказуемо: - записи идут последовательно - кэш работает эффективно - страницы заполняются полностью Это почти максимальная скорость, на которую способна твоя база. Случайные UUIDv4 UUIDv4 генерируются равномерно случайно. Вставка может попасть в любое место структуры B-дерева. Из-за хаотичного распределения: База должна постоянно подгружать случайные страницы с диска в память. Это random I/O. Page splitting: когда страница заполнена, ее приходится делить на две, оставляя обе наполовину пустыми. Эффект "швейцарского сыра": индекс раздувается, полон дыр и плохо использует RAM и место на диске. Когда размер индекса превышает доступную оперативку, пропускная способность записи может просесть на 20–90%. UUIDv7 Хватит использовать UUIDv4 в качестве primary key. Переходи на UUIDv7 (стандарт RFC 9562). UUIDv7 содержит timestamp в начале, так что значения становятся сортируемыми. Что это дает: Генерация без центрального счетчика Вставки идут монотонно, почти как обычные последовательные числа Фрагментация индекса исчезает Защита от угадывания ID (хотя по ID можно понять время вставки) Получается удобство UUID, но без потерь по производительности. Короче, UUIDv7 норм. UUIDv4 не особо, если используешь как primary key. 👉 @BackendPortal

Вопрос:

    
        try {
  call_order_service(); 
  call_inventory_service(); // уменьшаем остатки
} catch (Exception e) {
  // лол, и что теперь? Заказ уже создан.
}{}
    

Поздравляю. У тебя есть заказ на товар, которого нет на складе. И как ты это будешь фиксить? 👉 @BackendPortal