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

AdvCache — highload in-memory HTTP cache & reverse proxy на Go (production-ready) Кому и где полезен. k8s‑friendly слой кэширования на входе трафика: как ingress/edge‑кэш перед сервисами или sidecar рядом с ними. Подходит — там, где нужны стабильные SLO по латентности, разгрузка upstream и экономия железа. — Основа на fasthttp: предсказуемая латентность, hot‑path = zero allocs. — Per‑shard LRU (честные списки) или redis‑style LRU sampling — выбирайте под профиль нагрузки. — Входная W‑TinyLFU + Doorkeeper/Count‑Min: агрессивная фильтрация шума → выше hit‑rate. — β‑refresh (стохастическое обновление до TTL), управление upstream (health‑пробы, карантин, лимиты). — Потоковое сжатие ответов, метрики Prometheus/VictoriaMetrics, дампы с CRC32, лёгкий оркестратор воркеров. — Бенчмарки и E2E‑тесты в репозитории; код — production. Цифры. Bare metal, 12 ядер: 250 000 RPS при среднем документе ≈ 5.5 КБ. При заполнении хранилища 50 ГБ — GC‑pause ≈ 5 мкс. 🔒 Лицензия: Apache‑2.0 GitHub ⭐️ https://github.com/Borislavv/adv-cache #Go #Golang #HighLoad #Cache #LRU #TinyLFU #ReverseProxy #fasthttp #Performance #OpenSource

Каждый разработчик в растущем e-commerce сталкивался с этим вопросом: Как масштабировать процесс создания заказов во время флеш-распродажи? Есть 4 варианта. Работает только один. Разберём по порядку: I. Синхронное создание заказа . Запрос блокируется. . Запись в БД в "горячем" пути. . Ложится под нагрузкой. . Не масштабируется. II. Асинхронная обработка через очередь ✅ . Принимаем заказ. . Кладём его в очередь. . Быстро возвращаем ответ. . Обрабатываем позже. Это развязывает API и нагрузку: . Масштабируется. . Переживает пиковые всплески. . Даёт контроль. . Работает, потому что очередь берёт удар на себя. III. Централизованный сервис заказов . Один большой сервис. . Один большой bottleneck. . Код проще, проблемы те же. . Разваливается на масштабе. IV. Сплошные микросервисы . Вносит задержки, координацию и новые точки отказа. . Всё ещё не сглаживает пиковую нагрузку. . Инструмент не для этой задачи. Компромиссы (они всегда есть): I. Eventual consistency. II. Нужна идемпотентность (и так критично). III. Нужно мониторить состояние очереди. IV. Требуются компенсирующие транзакции. V. Очередь сама по себе не решает всё. 👉 @BackendPortal

Краткая шпаргалка по шаблонам проектирования Автор: Jason McDonald. 👉 @BackendPortal

Клиентское кэширование в HTTP работает так Сервер может отдавать два типа ресурсов — статические и динамические. Статические данные не меняются между запросами, поэтому их можно кэшировать на стороне клиента с помощью специальных HTTP-заголовков. Когда клиент впервые делает GET-запрос к ресурсу, локальный кэш проверяет его наличие. Если ресурса нет, запрос уходит на сервер. Сервер в ответе указывает, что данные можно закэшировать -> заголовок Cache-Control задаёт время жизни ресурса, а ETag определяет его конкретную версию. Кэш сохраняет ответ и возвращает его клиенту. При повторном запросе, если ресурс ещё актуален, кэш сразу отдаёт его клиенту, минуя сервер. Однако сервер может обновить ресурс до истечения срока жизни в кеше, поэтому данные в кеше и на сервере не всегда строго согласованы. Обычно это приемлемо, а чтобы гарантировать обновление, сервер просто меняет версию ресурса. Если ресурс в кеше устарел, кэш отправляет новый запрос на сервер с условным заголовком, например If-None-Match, где указывает сохранённую версию. Если сервер имеет новую версию, он возвращает её. Если изменений не было, он отвечает кодом 304 Not Modified, и клиент продолжает использовать локальные данные. 👉 @BackendPortal

Вопрос по системному дизайну Как убедиться, что реплика синхронизирована с мастером и что данные корректны? Мастер отправляет репликам логические операции, которые они применяют по порядку:

    
        {"op": "add", "id": "apple"}
{"op": "add", "id": "apple"}
{"op": "remove", "id": "orange"}{}
    

После того как реплика обработала эти изменения (добавила два яблока, удалила один апельсин), как проверить, что оба узла в итоге пришли к одному и тому же состоянию? Требования: • Проверка должна работать за O(delta), где delta — это набор применённых изменений • Проверка состояния должна занимать минимально возможное количество памяти Дополнительно: • Должна быть поддержка операций удаления • Может ли система определить, где произошло расхождение? • Может ли она определить, когда произошло расхождение? 👉 @BackendPortal

Как backend-разработчику в 2025 году оставаться востребованным Изучи эти 11 навыков I. Проектирование API — REST, GraphQL, gRPC. II. Аутентификация и авторизация — OAuth2, JWT, OpenID Connect, Passkeys. III. Базы данных — SQL, NoSQL, шардинг, индексы, оптимизация запросов. IV. Кэширование — Redis, CDN, стратегии edge-кэширования. V. Событийно-ориентированные системы — Kafka, Pulsar, стриминговые пайплайны. VI. Конкурентность и асинхронность — реактивное программирование, структурированная конкуренция. VII. Распределённые системы — микросервисы, service mesh, eventual consistency. VIII. Безопасность — HTTPS, шифрование, zero trust, OWASP top 10. IX. Обсервабилити — логирование, трассировка, метрики, OpenTelemetry. X. Облако и деплоймент — Docker, Kubernetes, serverless, GitOps. XI. Интеграция ИИ — LLM API, векторные базы данных, retrieval-augmented системы. Хватит прыгать с одного языка на другой. 👉 @BackendPortal

ПРИМИ УЧАСТИЕ В SMOLATHON 2025 🚀 Любимый многими хакатон возвращается! 16-17 октября 2025 года в Смоленске пройдет масштабный хакатон по созданию цифровых решений для городской среды! Хакатон проходит в рамках международного молодежного ИТ-форум [Свой код]. [Свой Код] — это новая площадка для молодежи, которой интересны технологии и инновации, которая хочет расти и развиваться профессионально в технологической среде, заинтересована в построении своей карьеры или хочет стать технологическим предпринимателем. В рамках форума предусмотрены развлекательная программа, лекции и мастер-классы, выставка технологий. На этот раз участникам предстоит разработать веб-платформу для Центра организации дорожного движения Смоленской области. 🚨 Обрати внимание, в этом году хакатон пройдет в два этапа. Прояви себя в отборочном этапе и пройди в финал крутого IT-события осени! Сохраняй даты: • Отборочный онлайн-этап: 22 сентября - 3 октября 2025 года • Очный финал: 16-17 октября для лучших 20 команд 💡 Тебя ждет: • Решение актуальной задачи для города • Призовой фонд 500 000 рублей • Новые знакомства с IT-сообществом 👥 Собери dream team из 2-5 человек и покажи, на что способны настоящие разработчики. 📌 Важно: каждый участник регистрируется индивидуально на сайте https://clck.ru/3PEEAp, а капитан команды отмечает свой статус при регистрации. Успей зарегистрироваться до 20 сентября 2025 года.

Консистентность «read-your-writes» означает, что любая запись, сделанная в базу данных, сразу становится доступной для чтения тем же клиентом. Звучит очевидно, но бывают ситуации, когда это правило не выполняется, особенно при работе на больших масштабах. На сервере с одной нодой это легко гарантировать при использовании последовательных транзакций. В среде с primary и replica всё сложнее. Во многих базах данных все записи и часть чтений обрабатываются на primary, а большая часть чтений выполняется на репликах. Из-за задержки репликации может возникнуть ситуация, когда клиент записывает данные в базу и тут же пытается их прочитать с реплики, но записи там ещё нет. Такое возможно при использовании асинхронной или полусинхронной репликации, так как они не требуют, чтобы все реплики получили данные до ответа клиенту. При синхронной репликации primary отвечает только после того, как все реплики подтвердят получение записи. Если используется асинхронная или полусинхронная репликация, чтения на реплики лучше направлять только тогда, когда консистентность «read-your-writes» не критична. 👉 @BackendPortal

Как работает ветвление по Gitflow? 👉 @BackendPortal