15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Redis — хранилище данных, которое работает преимущественно в оперативной памяти. Его используют для кеширования, хранения сессий, ограничения запросов, рейтингов и обмена сообщениями.
Почему Redis быстрый? Работа с данными в RAM и эффективные структуры данных позволяют выполнять многие операции с низкой задержкой. Но противопоставление «Redis — память, обычная БД — диск» слишком упрощённое: базы данных тоже активно используют память и кеширование.
Что можно хранить? Redis поддерживает строки, хеши, списки, множества, отсортированные множества и Streams. Также есть битовые карты и HyperLogLog для приблизительного подсчёта уникальных элементов.
Где применяется Redis:
• Кеширование: карточки товаров, профили пользователей, ответы API.
• Сессии: общее хранилище для нескольких экземпляров приложения.
• Rate limiting: учёт запросов и ограничение частоты обращений.
• Рейтинги: Sorted Sets позволяют хранить участников с баллами и получать лидеров.
• Pub/Sub: публикация сообщений для активных подписчиков. Для сценариев с сохранением сообщений и подтверждениями обработки есть Streams.
Как работает кеширование: Приложение сначала проверяет Redis. Если данные найдены, возвращает их клиенту. Если нет — обращается к основной БД, сохраняет результат в Redis с заданным TTL и возвращает ответ.
Это снижает нагрузку на базу и ускоряет повторные запросы. В такой архитектуре основная БД остаётся источником истины, а Redis хранит временные копии данных.
Следующая задача — понять, когда эти копии устарели и как их обновлять. Именно для этого нужна инвалидация кеша.
👉 @BackendPortal
Backend-совет: держите транзакции короткими
Не открывайте транзакцию перед вызовом внешнего API, который может отвечать 10 секунд. Всё это время соединение с БД может оставаться занятым, а блокировки — мешать другим запросам.
По возможности выполняйте внешние вызовы вне транзакции, оставляя внутри только необходимые операции с БД.
👉 @BackendPortal
GitHub-репозитории для прокачки навыков
Подборка по AI, проектированию систем, автоматизации, подготовке к собеседованиям, API и инструментам разработчика. Материалы, которые помогут разобраться в новых темах и применить знания в реальных проектах.
👉 @BackendPortal
API Gateway, BFF и Reverse Proxy: в чём разница? Все три могут находиться между клиентом и бэкендом, но решают разные задачи.
• API Gateway — единая точка входа в API. Маршрутизирует запросы к сервисам и централизует общие функции: проверку токенов, ограничение частоты запросов, логирование, иногда агрегацию ответов.
Полезен, когда нескольким сервисам нужны единые правила обработки API-запросов.
• BFF — бэкенд под конкретный фронтенд. Backend for Frontend адаптирует данные и операции под потребности веб-приложения, мобильного клиента или Smart TV.
Например, мобильному приложению нужен компактный ответ с товаром, ценой и наличием. BFF собирает эти данные из нескольких сервисов и возвращает их одним запросом. Имеет смысл, когда потребности клиентов заметно различаются.
• Reverse Proxy — обратный прокси перед серверами. Принимает клиентские запросы и перенаправляет их бэкендам. Может выполнять балансировку нагрузки, завершение TLS, кеширование и сжатие.
Его основная задача — управлять передачей трафика к внутренним серверам.
Это не обязательно три отдельных компонента. API Gateway часто построен на обратном прокси и расширяет его возможности. BFF может работать за шлюзом. В одной архитектуре могут использоваться все три подхода, но добавлять каждый из них без конкретной задачи не нужно.
Запомнить просто:
• API Gateway — общие правила для API.
• BFF — API под потребности конкретного клиента.
• Reverse Proxy — приём и перенаправление трафика к бэкендам.
👉 @BackendPortal
Sticky Sessions и Stateless: в чём разница?
При Sticky Sessions балансировщик направляет запросы одного пользователя на один и тот же сервер. Это удобно, если приложение хранит сессию в памяти конкретного экземпляра.
Например, корзина хранится на сервере A — значит, запросы пользователя должны попадать именно туда. Если сервер упадёт, состояние может потеряться, если нет репликации или внешнего хранилища.
При Stateless-подходе обработка запроса не зависит от локальной сессии на конкретном сервере. Любой экземпляр приложения может принять запрос и проверить переданные учётные данные, например JWT.
Так проще распределять нагрузку, добавлять экземпляры и продолжать работу при отказе одного из них.
Важный нюанс: сессии в общем Redis тоже позволяют направлять запросы на любой сервер. Но это всё ещё серверные сессии: состояние просто вынесено из памяти приложения во внешнее хранилище.
Когда что выбирать:
• Sticky Sessions — когда существующее приложение зависит от локальных сессий, а изменить его архитектуру пока сложно.
• Stateless или общее хранилище сессий — когда нужны независимое масштабирование экземпляров и устойчивость к их перезапускам.
Отсутствие привязки к серверу не означает отсутствие аутентификации. Проверять пользователя и его права нужно при любом подходе.
👉 @BackendPortal
Отключить кнопку «Отправить» — ещё не значит обеспечить идемпотентность.
Пользователь может обновить страницу, повторить запрос после тайм-аута, открыть несколько вкладок или отправить запрос заново. Для legacy-системы можно использовать такую схему:
React → UUID операции → Node API → MongoDB с уникальным индексом → Legacy Backend.
Как это работает:
• Клиент создаёт UUID для логической операции и повторно использует его при ретраях.
• Node API атомарно регистрирует операцию в MongoDB со статусом PROCESSING. Уникальный индекс предотвращает регистрацию дубликатов.
• Если операция уже существует, API возвращает сохранённый результат или текущий статус.
• Если операция новая, API вызывает legacy-бэкенд и сохраняет результат со статусом COMPLETED или FAILED.
• Cuckoo Filter может ускорять предварительные проверки, но не заменяет проверку в базе: возможны ложноположительные срабатывания.
Важный нюанс: уникальный индекс защищает от дублирования записей, но сам по себе не гарантирует однократное выполнение операции в legacy-бэкенде. Если тот выполнил действие, а ответ потерялся, нужны поддержка того же ключа на его стороне или механизм сверки результата.
👉 @BackendPortal
Что такое Circuit Breaker в микросервисах?
Когда зависимый сервис тормозит или возвращает ошибки, продолжать отправлять ему запросы — значит усугублять проблему. Circuit Breaker («предохранитель») временно прекращает обращения к такому сервису, помогая предотвратить каскадные сбои и защитить остальную систему.
Как работает Circuit Breaker:
• Closed — замкнут: всё в норме, запросы проходят как обычно.
• Open — разомкнут: превышен порог ошибок, обращения к сервису временно блокируются.
• Half-Open — полуоткрыт: после паузы пропускается ограниченное число пробных запросов, чтобы проверить восстановление сервиса.
Если проверки успешны, Circuit Breaker возвращается в Closed. Если ошибки продолжаются — снова переходит в Open.
Что это даёт:
• Повышает отказоустойчивость.
• Сокращает ожидание при сбоях благодаря быстрому отказу.
• Помогает сохранить стабильность системы.
👉 @BackendPortal
TLS termination: зачем завершать TLS на балансировщике
Идея проста: вместо того чтобы каждый бэкенд-сервер занимался шифрованием и расшифровкой трафика, эту работу берёт на себя балансировщик нагрузки.
Когда клиент подключается, TLS-рукопожатие происходит между браузером и балансировщиком. Балансировщик использует свой сертификат, устанавливает защищённое соединение и расшифровывает входящий HTTPS-трафик.
Дальше в такой схеме запросы передаются бэкенд-серверам по обычному HTTP внутри приватной сети. Серверы приложения не управляют сертификатами и не тратят ресурсы на обработку TLS. Обновлять и заменять сертификаты тоже проще: всё сосредоточено в одном месте.
Важный нюанс: соединение зашифровано только до балансировщика. Передача по HTTP внутри сети допустима, если это соответствует требованиям безопасности; при необходимости участок от балансировщика до бэкенда тоже защищают TLS.
👉 @BackendPortal
6 инструментов в закладки бэкенд-разработчику
• Hoppscotch — тестирование API и просмотр ответов.
• Webhook.site — отладка вебхуков и проверка их содержимого.
• dbdiagram.io — визуализация схем баз данных.
• Dalibo Explain — разбор планов выполнения запросов PostgreSQL.
• ngrok — доступ к локальному серверу извне для тестирования.
• Sentry — отслеживание и отладка ошибок в продакшене.
ИИ помогает писать бэкенд. Эти инструменты помогают проверять, как он работает.
👉 @BackendPortal
Правильный ответ: Запустите git reflog, чтобы посмотреть недавние положения HEAD и найти хеш коммита, на который указывала удалённая ветка.
Затем восстановите ветку:
git checkout -b your-branch-name <хеш-коммита>
От DNS до Pod: как работает Kubernetes Gateway API
Типичная схема с облачным балансировщиком выглядит так:
• Вы создаёте DNS-запись, которая указывает на IP облачного Load Balancer.
• Балансировщик направляет трафик в Kubernetes Service, обслуживающий шлюз.
• Service передаёт запросы Pod’ам прокси — например, NGINX или Envoy.
• Gateway Controller отслеживает ресурсы HTTPRoute, GRPCRoute и другие поддерживаемые маршруты.
• Когда вы применяете эти ресурсы, контроллер обновляет конфигурацию прокси.
• Правила в HTTPRoute определяют, куда направлять запросы: например, /payment — в payment-service, а /auth — в auth-service.
Путь запроса после разрешения DNS:
Cloud Load Balancer → Service шлюза → Gateway Proxy → Backend Service → Pod.
Если вы знакомы с Ingress, разобраться в этой схеме будет проще. При этом разделение контроллера и прокси встречается и в Ingress: контроллер управляет конфигурацией, а прокси обрабатывает трафик.
Особенность Gateway API — явное разделение настройки инфраструктуры и маршрутизации через ресурсы GatewayClass, Gateway и HTTPRoute, которое позволяет распределять ответственность между платформенной командой и разработчиками.
👉 @BackendPortal
Слышали о zip_longest из itertools?
Наверняка вы знакомы с zip(). Эта функция объединяет элементы нескольких итерируемых объектов по позициям, пока один из них не закончится.
Это удобно, когда объекты имеют одинаковую длину. Но если длины различаются, zip() остановится на самом коротком.zip_longest() из itertools работает иначе: продолжает объединение, пока не закончится самый длинный объект. А недостающие значения можно заполнить выбранным вами значением.
А вы уже использовали zip_longest()?
👉 @BackendPortal
Docker прост, пока всё работает.
Но что делать, если контейнер постоянно перезапускается, логи пропали, а приложение теряет данные после перезапуска? Тут уже недостаточно одного docker run.
Команды Docker, которые стоит знать каждому разработчику:
• docker logs -f → следить за логами приложения.
• docker exec -it → выполнять команды внутри работающего контейнера для диагностики.
• docker inspect → изучать конфигурацию контейнера.
• docker stats → проверять потребление CPU и памяти.
• docker network → управлять сетями и разбираться с соединениями между сервисами.
• docker volume → управлять томами для хранения данных вне жизненного цикла контейнера.
• docker compose → запускать несколько сервисов вместе.
• docker system df → проверять, сколько места на диске занимает Docker.
В продакшене не забывайте:
• Использовать небольшие базовые образы из доверенных источников.
• Запускать приложение от пользователя без прав root.
• Настраивать проверки работоспособности и ограничения ресурсов.
• Не хранить секреты в Docker-образах.
• Использовать тома для постоянного хранения данных.
Подготовили шпаргалку по Docker для продакшена: архитектура, команды, примеры, сети, тома, Compose и советы по диагностике проблем.
👉 @BackendPortal
10 GitHub-репозиториев по бэкенд-разработке, о которых стоит знать каждому разработчику:
• Awesome Scalability
• Full Stack FastAPI Template
• Awesome System Design Resources
• Backendlore
• Backend Challenges
• Web Skills
• .NET Backend Developer Roadmap
• Simple Bank
• Backend Cheats
• Backend Best Practices
👉 @BackendPortal
Задача для дата-инженера
Что произойдёт при вызове этой функции?
👉 @BackendPortal
Pandas: от загрузки данных до готового отчёта
Библиотека для анализа данных в Python, с которой можно пройти весь рабочий процесс: загрузить файлы, изучить структуру данных, выбрать столбцы, отфильтровать строки и обработать пропуски.
Дальше — сгруппировать результаты, объединить таблицы, поработать с датами, построить графики и экспортировать итоговые данные.
👉 @BackendPortal
Cookies, Sessions и JWT: не путайте эти понятия
Они часто используются вместе, но отвечают за разные вещи.
• Cookie — механизм хранения и передачи данных в браузере
Небольшой фрагмент данных, который браузер сохраняет и автоматически отправляет с запросами, подходящими под правила cookie: домен, путь и другие ограничения. Cookie может содержать идентификатор сессии или JWT.
• Session — состояние пользователя на сервере
Сервер хранит данные сессии, например в памяти, Redis или базе. Браузер обычно получает только её идентификатор и передаёт его через cookie. Так сервер может управлять сессиями и отзывать их при выходе пользователя.
• JWT — формат токена с набором утверждений (claims)
Может содержать идентификатор пользователя, срок действия и другие данные. Подписанный JWT можно проверить без хранения отдельной серверной сессии.
Но содержимое токена само по себе не доказывает личность: нужно проверить подпись и необходимые claims. Подпись также не скрывает данные токена.
Запомнить просто:
• Cookie — как браузер хранит и передаёт данные.
• Session — как сервер хранит состояние между запросами.
• JWT — в каком формате передаются утверждения.
Это не три взаимоисключающих способа входа: и идентификатор сессии, и JWT можно передавать в cookie.
👉 @BackendPortal
7 бесплатных ресурсов для разработчиков
В подборке API, базы данных, SVG-логотипы и инструменты для разработки.
1. itsfree.ai — каталог AI-моделей и API с бесплатными тарифами
2. publicapis.dev — более 1400 публичных API для ваших проектов
3. svgl.app — сотни SVG-логотипов компаний и продуктов
4. Turso — до 100 облачных баз SQLite и 5 ГБ бесплатно
5. CodeRabbit — AI-проверка pull request для open-source проектов
6. Resend — API для отправки до 3000 писем в месяц
7. UptimeRobot — мониторинг до 50 сайтов и API
OAuth Scopes, Roles и Permissions: в чём разница? Эти понятия часто встречаются вместе, но отвечают за разные аспекты авторизации.
• Scopes — область доступа, предоставленная клиентскому приложению через токен. Например, токен разрешает читать контакты, но не изменять их. Scopes используются как для сторонних интеграций, так и для собственных API, включая взаимодействие между сервисами без участия пользователя.
• Roles — роли, объединяющие наборы прав. Администратор, менеджер, сотрудник поддержки. Роль описывает обязанности пользователя в системе и упрощает управление доступом.
• Permissions — права на конкретные действия. Например: customer.read, customer.update, order.create или invoice.approve.
Как это выглядит в CRM: Сотрудник входит через Google с помощью OpenID Connect. Если CRM нужен доступ к его Google-контактам, она отдельно запрашивает соответствующий OAuth scope.
Внутри CRM сотруднику назначена роль «Менеджер по продажам». Она даёт права просматривать клиентов и создавать заказы, но не обязательно позволяет согласовывать счета.
Доступ к Google-контактам не делает пользователя администратором CRM. И роль администратора CRM сама по себе не даёт приложению доступ к Google API. При обработке запроса API проверяет токен, необходимые scopes и права пользователя — в зависимости от своей модели доступа. Также могут потребоваться проверки владельца ресурса, организации и других условий.
Запомнить просто:
• Scopes ограничивают доступ по токену.
• Roles объединяют права.
• Permissions разрешают конкретные действия.
OAuth 2.0 отвечает за делегированный доступ, а OpenID Connect добавляет аутентификацию пользователя. Использовать все три механизма в каждой системе необязательно: выбор зависит от требований.
👉 @BackendPortal
Inbound и Outbound: всё зависит от направления
Чтобы разобраться, определите, относительно какого сервиса или системы вы рассматриваете трафик.
Inbound — входящий трафик
Запросы приходят в вашу систему:
• Браузер → ваш сервер.
• Мобильное приложение → Backend API.
• Другой микросервис → ваш сервис.
Ваша система принимает запрос.
Outbound — исходящий трафик
Ваша система сама инициирует обращение:
• Бэкенд → платёжный шлюз.
• Бэкенд → банковский API.
• Бэкенд → база данных или кеш.
• Бэкенд → почтовый сервис.
• Ваш сервер → другой внутренний или внешний сервис.
Пример: приложение доставки еды
Пользователь запрашивает ближайшие рестораны — это Inbound для бэкенда. Затем бэкенд обращается к сервису карт или рекомендаций — это Outbound для него.
Один и тот же запрос может быть исходящим для сервиса A и входящим для сервиса B. Меняется только точка отсчёта. При диагностике спросите себя: «Запрос приходит в мой сервис или мой сервис обращается к другому?» Это помогает разобраться в логах, правилах межсетевого экрана, прокси и взаимодействии микросервисов.
👉 @BackendPortal
⚡️⚡️Строки кода стремятся подешеветь до цены токена. Что остается ценным?
Про это — трек «Замысел» 15 октября. Во второй день Joker, посвященный разработке будущего. О том, как человек понимает, почему он называет что-то проблемой, и формулирует свою цель, а не ту, что навязана ему извне. Теперь это общая работа для всех ролей, от разработчика до CEO: шаблонными решениями и готовыми схемами думает модель.
В карточках к посту рассказываем, почему так получилось, и показываем доклады из трека: спикеры расскажут, о чем нужно подумать еще до постановки задачи, и чем будет заниматься новый тип инженера — Context Engineer.
К дискуссиям после докладов — собираем ваши кейсы. Напишите в комментариях поста, если у вас бывало такое:
— агент час работал не над той задачей, потому что задача была сформулирована плохо;
— ускорение одного этапа не сдвинуло общий срок;
— узким местом оказалась не модель или инфраструктура, а знание, которое никто не записал.
Joker 2026 — 14–15 октября, Санкт-Петербург и онлайн.
🌟По промокоду BackendPortal персональные билеты дешевле
▶️ Исследуйте разработку будущего — на сайте Joker.
Реклама. ООО «Джуг Ру Груп». ИНН 7801341446
30 вопросов для подготовки к собеседованию на бэкенд-разработчика:
• Расскажите об архитектуре бэкенд-приложения, над которым вы работали.
• Чем отличаются REST, SOAP и GraphQL?
• Как спроектировать масштабируемый REST API?
• Что такое HTTP-методы и когда использовать GET, POST, PUT, PATCH и DELETE?
• Какие HTTP-коды состояния вы чаще всего используете в бэкенд-разработке?
• Как организовать аутентификацию и авторизацию в приложении?
• Чем аутентификация на основе сессий отличается от аутентификации с JWT?
• Как безопасно хранить пароли в базе данных?
• Что такое middleware и для чего оно используется?
• Как обрабатывать ошибки и исключения в бэкенд-сервисе?
• Чем синхронная обработка отличается от асинхронной?
• Как повысить производительность медленного API?
• Что такое индексы в базе данных и когда их стоит использовать?
• Чем отличаются SQL- и NoSQL-базы данных?
• Как проектировать схему базы данных для масштабируемого приложения?
• Что такое транзакции и почему важны свойства ACID?
• Что такое пул соединений и зачем он нужен?
• Как защититься от SQL-инъекций и других распространённых уязвимостей?
• Что такое кеширование и где в бэкенд-системе пригодится Redis?
• Что такое очередь сообщений и в каких случаях выбрать Kafka, RabbitMQ или другой брокер?
• Как спроектировать бэкенд, способный обрабатывать миллионы запросов?
• Чем горизонтальное масштабирование отличается от вертикального?
• Что такое микросервисы и когда стоит предпочесть их монолиту?
• Как микросервисы взаимодействуют друг с другом?
• Как организовать версионирование API, не нарушая работу существующих клиентов?
• Как настроить логирование, мониторинг и наблюдаемость бэкенд-сервисов?
• Как тестировать бэкенд-приложения? Объясните разницу между unit-, интеграционными и end-to-end-тестами.
• Как организовать фоновые задачи и выполнение заданий по расписанию?
• Напишите API с CRUD-операциями и объясните свою реализацию.
API в продакшене внезапно замедлился или начал возвращать ошибки. • Как вы будете искать причину?
Список — ориентир для подготовки: конкретные вопросы зависят от компании, позиции и уровня специалиста.
👉 @BackendPortal
HTTP-коды проще понять, если запомнить пять групп
• 1xx — информационные ответы. Запрос принят, обработка продолжается.
• 2xx — успех. Запрос успешно получен, понят и принят.
• 3xx — перенаправления. Для завершения запроса нужны дополнительные действия, например переход по другому URL.
• 4xx — ошибки клиента. Некорректные данные, отсутствие аутентификации или обращение к несуществующему эндпоинту.
• 5xx — ошибки сервера. Сервер не смог выполнить запрос из-за ошибки на своей стороне.
Знание этих категорий помогает быстрее разбираться в проблемах API, балансировщиков и обратных прокси, а также понимать, что происходит в логах.
👉 @BackendPortal
План оптимизации SQL-запросов
Правильный результат ещё не означает, что запрос работает эффективно. Если SQL начинает тормозить, не переписывайте его наугад.
План выполнения (EXPLAIN) → фильтры → выбираемые столбцы → JOIN → индексы → функции → перемещение данных → повторные замеры.
Оптимизируйте на основе фактов, а не догадок. Что вы проверяете первым, когда SQL-запрос становится медленным?
👉 @BackendPortal
Вы случайно удалили ветку Git.
Она не была слита, и ни у кого больше нет её копии. Ссылка ветки на коммиты исчезла.
Можно ли ещё восстановить эту ветку?
👉 @BackendPortal
Партиционирование vs шардинг: в чём разница?
Таблица растёт, запросы замедляются, обслуживать данные становится сложнее. Партиционирование и шардинг помогают разделить данные на части, но решают разные задачи.
Партиционирование разбивает большую таблицу на разделы, например по месяцам. В показанном сценарии они остаются на одном сервере. Это упрощает обслуживание и позволяет подходящим запросам читать только нужные разделы.
Шардинг распределяет данные между несколькими серверами по ключу, например user_id или tenant_id. Это позволяет распределять нагрузку и объём хранения, но усложняет запросы между шардами и перенос данных.
Оба подхода можно сочетать: внутри каждого шарда таблицы могут быть партиционированы. Сохраняйте схему
👉 @BackendPortal
20 концепций бэкенд-разработки, которые стоит знать каждому разработчику
• REST API — создание веб-сервисов на основе принципов REST.
• GraphQL — гибкий язык запросов к API.
• Аутентификация — проверка личности пользователя.
• Авторизация — управление доступом к ресурсам.
• JWT — формат токенов, применяемый в том числе в аутентификации без хранения сессий на сервере.
• CRUD — создание, чтение, обновление и удаление данных.
• SQL-базы данных — хранение структурированных данных в связанных таблицах.
• NoSQL-базы данных — хранение данных в документной модели, формате «ключ — значение» и других моделях.
• Индексы БД — ускорение выполнения запросов.
• Кэширование — снижение задержек с помощью Redis или Memcached.
• Очереди сообщений — асинхронное взаимодействие между сервисами.
• Микросервисы — построение приложений из независимых сервисов.
• Rate limiting — ограничение частоты запросов для защиты API от злоупотреблений и перегрузки.
• Балансировка нагрузки — распределение трафика между серверами.
• WebSockets — двусторонний обмен данными в реальном времени.
• Логирование — запись событий приложения для диагностики.
• Мониторинг — отслеживание работоспособности и производительности приложения.
• Docker — контейнеризация бэкенд-приложений.
• CI/CD — автоматизация тестирования, доставки и развёртывания изменений.
• Обратный прокси — маршрутизация и защита входящего трафика с помощью Nginx или HAProxy.
👉 @BackendPortal
OAuth 2.0 и JWT: в чём разница и почему их не стоит противопоставлять
Эти понятия часто путают, хотя они решают разные задачи. OAuth 2.0 описывает, как приложение получает ограниченный доступ к ресурсам пользователя. JWT — формат токена, который содержит набор утверждений, например идентификатор пользователя и срок действия.
Пример OAuth 2.0: вы разрешаете стороннему приложению читать файлы из облачного хранилища, не передавая ему свой пароль. Приложение получает access token и использует его для обращения к API. Этот access token может быть JWT, но не обязан. В свою очередь, JWT можно использовать и вне OAuth 2.0.
Сохраняйте схему, чтобы запомнить главное: OAuth 2.0 — правила получения доступа, JWT — формат передачи утверждений.
👉 @BackendPortal
🤖 Как устроить ИИ-агента, который не развалится в проде?
6 октября в Архитектурном клубе Яндекс 360 разберут полную архитектуру агента для работы с корпоративными данными: от оркестратора и инструментов до памяти, поиска и наблюдаемости.
Даниил Смирнов, руководитель разработки ИИ-платформы Яндекс 360, расскажет о правах доступа и изоляции данных, ограничении автономности и оценке качества на каждом этапе — от поиска и выбора инструмента до итогового ответа.
🗓 6 октября, 17:00 МСК
💻 Онлайн, бесплатно
→ Зарегистрироваться на эфир
Приложение тормозит? Проблема не всегда в бэкенде.
Иногда пользователи просто находятся слишком далеко от вашего сервера.
• Здесь на помощь приходит CDN:
• Кэширование на пограничных серверах
• Попадание и промах кэша
• Снижение задержек
• Примеры использования на практике
👉 @BackendPortal