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

API требуют ограничения скорости (rate limiting), чтобы один всплеск трафика не перегрузил весь сервис. В этом гайде yongdev показывает, как реализовать rate limiting по алгоритму token bucket в FastAPI, построив его с нуля. По ходу вы разберётесь с rate limit заголовками, обработкой 429 (Too Many Requests) и тем, как этот паттерн вписывается в реальную архитектуру API. 👉 @BackendPortal

Хватит кодить руками: Инструкция, как управлять нейросетями и собирать IT-продукты за вечер Самое странное сейчас это пытаться кодить руками по классике, когда опытные программисты давно кодят с нейронками даже в больших проектах. Поэтому в 2026 выигрывает тот, кто быстро делает рабочие решения без долгих лет обучения и максимально сокращает путь с нуля до первого реального проекта в IT. Андрей Ивашев запускает бесплатный 3-дневный интенсив: «Вайбкодинг: с нуля до первого IT-продукта» 📅 7-9 апреля в 19:00 МСК Для тех хочет начать программировать с нейронками, создать свой первый IT-продукт и заработать на этом первые деньги даже без опыта и образования. Программа 🔥 7 апреля Почему сегодня вход в IT стал сложнее и как вайбкодинг меняет правила игры 8 апреля 3 способа заработать на вайбкодинге в 2026 и где брать первого клиента, чтобы сделать проект за реальные деньги 9 апреля Эра агентов или программирование на автопилоте 🎁 Бонус за регистрацию: «Библиотека промптов для заработка на вайбкодинге», которые помогут упаковать портфолио и общаться с клиентами так, чтобы покупали. 50 бесплатных нейросетей, чтобы вы могли кодить без остановки + секретные бонусы Бесплатных мест для наших подписчиков всего 100. Зарегистрироваться бесплатно Зарегистрироваться бесплатно Зарегистрироваться бесплатно Тыкни на 🔥, если идёшь.

Существует множество способов выполнить один и тот же запрос в Postgres. - Делать поиск через последовательное сканирование (sequential scan) или по индексу? - Какие индексы использовать? - В каком порядке лучше джойнить таблицы? - Какой алгоритм сортировки выбрать? Все эти решения принимает query planner. Его задача — принять запрос, определить оптимальный план выполнения, а затем передать его в execution engine. Postgres собирает статистику по каждой таблице (размер, оценка кардинальности колонок и т.д.), и эти данные используются планировщиком, помогая ему принимать более точные решения. Однако здесь есть риск: по мере обновления статистики планировщик может изменить план выполнения для уже существующих запросов. Обычно он принимает правильные решения, но иногда может выбрать новый план, который ухудшит производительность. В таких случаях можно: - настраивать параметры, например enable_seqscan=off - вручную обновлять статистику - или использовать расширения вроде pg_hint_plan, чтобы подсказать планировщику более подходящий вариант выполнения 👉 @BackendPortal

System Design Инвалидация кэша — проблема, которая сломала больше продакшн-систем, чем почти любой другой баг. В компьютерных науках есть всего две по-настоящему сложные задачи. Это — первая. Сегодня я покажу, почему это действительно сложно и какие практические стратегии реально работают. 1/ Основная проблема Вы кэшируете профиль пользователя. Пользователь обновляет свой email. В базе данных уже новый email, но в кэше всё ещё старый. Пользователь видит устаревшие данные и начинает путаться. Инвалидация кэша — это по сути поддержание кэша и базы данных в идеально синхронизированном состоянии. Ошиблись — и вы отдаёте неактуальную информацию. 2/ Почему это на удивление сложно База обновилась в 10:00:00.000. Другой сервер проверяет кэш в 10:00:00.001. Этого микроскопического зазора достаточно, чтобы проскочили устаревшие данные. В распределённых системах тайминги никогда не идеальны. Нельзя просто очистить кэш и надеяться на лучшее. Нужна чёткая стратегия. 3/ Стратегия 1: TTL (Time To Live) Самый простой подход. При сохранении данных в кэш задаётся время жизни. Пример в Redis:

    
        redis.setex("user:123", 300, user_data)  # истекает через 5 минут{}
    

Плюсы: автоматическая очистка и очень простая реализация. Минусы: данные могут оставаться устаревшими вплоть до полного TTL. Подходит для данных, которые редко меняются. 4/ Стратегия 2: Write-Through Cache Обновляете базу и кэш одновременно.

    
        def update_user(id, data):
    db.update(id, data)
    redis.set("user:" + id, data){}
    

Плюсы: кэш всегда актуален, нет stale reads. Минусы: запись становится медленнее (работаете с двумя системами), сбои кэша усложняют логику. Используется там, где данные должны быть строго актуальными. 5/ Стратегия 3: Write-Aside (самая распространённая) Сначала обновляете базу, затем просто удаляете запись из кэша.

    
        def update_user(id, data):
    db.update(id, data)
    redis.delete("user:" + id){}
    

Следующее чтение автоматически подтянет свежие данные и заново заполнит кэш. Плюсы: просто и хорошо работает при частичных обновлениях. Минусы: первое чтение после обновления чуть медленнее (cache miss). Подходит для большинства приложений. 6/ Реальный пример из продакшена E-commerce сайт кэширует цены товаров. Администратор обновляет цену. Пользователи всё ещё видят старую цену на checkout. Решение: при обновлении цены инвалидировать кэш товара и все связанные кэши (списки, категории). Следующий запрос пользователя сразу получает корректную цену. Никаких недовольных клиентов и ошибочных заказов. 7/ Проблема Thundering Herd Популярный cache key истёк. Одновременно приходит 1000 запросов. Все видят cache miss и начинают бомбить базу. База ложится под нагрузкой. Решение: использовать краткоживущую блокировку (lock), чтобы только один запрос пересобирал кэш, а остальные немного подождали. Один запрос к базе вместо тысячи. 8/ Самый популярный паттерн: Cache-Aside с lazy loading

    
        def get_user(id):
    cached = redis.get("user:" + id)
    if cached:
        return json.loads(cached)
    
    user = db.query("SELECT * FROM users WHERE id = %s", id)
    redis.setex("user:" + id, 300, json.dumps(user))
    return user{}
    

При обновлении просто удаляете ключ. Чисто, масштабируемо и повсеместно используется в продакшене. 9/ Многоуровневая инвалидация кэша В реальных системах часто несколько уровней кэша: - Redis (общий кэш) - In-memory кэш на каждом сервере - CDN на edge При изменении данных нужно инвалидировать каждый слой. Иначе где-то всё равно будут показываться устаревшие данные. Решение: рассылка событий инвалидации или явная очистка каждого уровня. 10/ Типичные ошибки, которые бьют по командам Никогда ничего не инвалидировать (вечный stale) Инвалидировать слишком агрессивно (кэш теряет смысл) Забывать про связанные кэши (списки, агрегации) Отсутствие защиты от cache stampede Кэширование сырых запросов к БД вместо финальных результатов Вместо этого: комбинируйте TTL с инвалидацией, чистите связанные данные, защищайтесь от stampede и мониторьте cache hit rate. 👉 @BackendPortal

Контейнеры против виртуальных машин 1. Использование ресурсов: Контейнеры используют ядро хостовой операционной системы, что делает их более легкими и быстрыми по сравнению с виртуальными машинами. Виртуальные машины имеют полноценную операционную систему и гипервизор, что делает их более ресурсоемкими. 2. Портабельность: Контейнеры разработаны с учетом портируемости и могут работать на любой системе с совместимой хостовой операционной системой. Виртуальные машины менее портируемы, так как для их работы требуется совместимый гипервизор. 3. Безопасность: Виртуальные машины обеспечивают более высокий уровень безопасности, поскольку каждая виртуальная машина имеет свою собственную операционную систему и может быть изолирована от хоста и других виртуальных машин. Контейнеры обеспечивают меньшее изолирование, так как они используют ядро хостовой операционной системы. 👉 @BackendPortal

Использование rate limiting ~ Ограничение скорости API применяется для того, чтобы предотвратить от одного пользователя слишком много запросов, которые могут замедлить работу системы. ~ Ограничение скорости веб-сервера используется для защиты сайта от слишком большого числа посетителей или атак. (например, сайт разрешает только 10 или 5 запросов в секунду с одного IP. Если кто-то пытается отправить больше запросов, его блокируют). Это помогает защитить систему от атак типа DoS. ~ Ограничение скорости базы данных используется для предотвращения слишком большого числа запросов к базе данных, что может привести к ее замедлению или поломке. (например, сайт электронной коммерции разрешает пользователю делать только 10 запросов к базе данных за 10 минут), чтобы избежать перегрузки системы и сохранить скорость работы приложения. ~ Ограничение скорости входа применяется для предотвращения атак, когда хакеры пытаются угадать пароли, делая много попыток. (разрешено только 2-3 попытки входа в минуту на пользователя). 👉 @BackendPortal

Яндекс открыл прием заявок в Школу бэкенд-разработки Зовем начинающих специалистов, желающих узнать, как писать код для высоконагруженных веб‑сервисов. Программа разделена на 2 трека: В Java-треке изучим инструменты разработки веб-приложений платформы Spring. Ещё в программе: многопоточность, базы данных и создание распределенных систем. В С++-треке освоим управление памятью, оптимизацию производительности и современное использование C++ в промышленной разработке. Для поступления нужно базово понимать один из языков — Python, Java или C++, уметь писать читаемый код и понимать основы алгоритмов и структур данных. Подать заявку можно здесь.

Маршрутизация трафика в Kubernetes: → ClusterIP: Тип сервиса по умолчанию, который предоставляет стабильный внутренний IP для взаимодействия внутри кластера. → NodePort: Открывает сервис на определённом порту на всех нодах (Nodes), позволяя получать к нему доступ извне через IP ноды. → LoadBalancer: Стандартный способ открыть сервис в интернет — создаётся внешний балансировщик нагрузки от облачного провайдера. → Ingress: Умный уровень маршрутизации, который управляет внешним HTTP/HTTPS-трафиком и направляет его к нескольким сервисам через одну точку входа. 👉 @BackendPortal

MVC-архитектура (Model–View–Controller) По мере роста приложений управлять кодом становится всё сложнее. Новички часто пишут всё в одном месте — бизнес-логику, пользовательский интерфейс и работу с данными. Для небольших проектов это ещё работает, но очень быстро такой код становится трудно поддерживать, отлаживать и масштабировать. MVC-архитектура решает эту проблему, вводя чёткое разделение ответственности (separation of concerns). Что такое MVC? MVC (Model–View–Controller) — это шаблон проектирования, который делит приложение на три основных компонента, каждый из которых отвечает за свою часть логики. Такое разделение делает код более организованным, читаемым и поддерживаемым. MVC — это способ структурировать код. Он делит приложение на 3 части: - Model = данные + логика - View = то, что видит пользователь - Controller = обрабатывает ввод и связывает Model и View Можно представить это так: Пользователь что-то нажимает → Controller обрабатывает Controller запрашивает данные у Model Model обрабатывает и возвращает результат Controller передаёт результат во View View отображает его пользователю Чисто. Структурировано. Предсказуемо. Что делает каждая часть? - Model — работает с данными Взаимодействует с базой данных и содержит бизнес-логику - View — отвечает за UI Только отображает данные, без логики - Controller — промежуточный слой Связывает Model и View Почему это важно? Без MVC → хаотичный код С MVC → структурированный код Преимущества: - Простая отладка - Лёгкие изменения - Лучшая масштабируемость Пример В системе логина: - Model проверяет учётные данные пользователя в базе - View отображает форму входа и сообщения (успех/ошибка) - Controller принимает ввод пользователя, валидирует его через Model и решает, какой View отобразить 👉 @BackendPortal

Асинхронные системы масштабируют вашу систему… и ваши проблемы. Большинство разработчиков осознают это только после того, как нарушается консистентность, и при этом на первый взгляд всё выглядит нормально. Асинхронность масштабирует вашу систему. Она также нарушает порядок. И вот откуда берутся большинство багов. Вот статья о том: - почему это происходит - как группировка решает проблему - и где она не работает Прочитайте здесь 👉 @BackendPortal