15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Что ты пишешь:
fetch("/users/123")
Когда понимаешь, что большинство операций копирования памяти выполняются на CPU — твой взгляд на software engineering меняется
Ты начинаешь иначе смотреть на программы видишь узкие места понимаешь мотивацию в pull request’ах от сеньоров и наконец полностью осознаёшь суть топовых докладов вроде этого про async I/O в Postgres
Баги которые раньше казались мистикой становятся очевидными
👉 @BackendPortal
Нашёл на YouTube плейлист по бэкенд-инжинирингу — начинается с HTTP и дальше разбирает роутинг, безопасность, масштабирование и прочее. Всё объяснено просто и понятно, реально полезный материал. Делюсь, может кому зайдёт.
👉 @BackendPortal
Паттерны проектирования систем - шпаргалка
🔸Webhooks и Outbox
Надёжные внешние уведомления.
Когда использовать — интеграции, сторонние колбэки.
Типичные проблемы — статусы оплат, синхронизация CRM.
🔸Blob/Object Storage
Дешёвое хранение больших файлов.
Когда использовать — медиа, бэкапы, экспорты.
Типичные проблемы — загрузки пользователей, data lake.
🔸Оркестратор задач (Airflow/Temporal)
Долгоживущие процессы с состоянием.
Когда использовать — длинные задачи, SLA.
Типичные проблемы — генерация отчётов, обработка видео.
🔸Blue-Green / Canary деплой
Постепенное переключение трафика.
Когда использовать — безопасные релизы, быстрый откат.
Типичные проблемы — деплой API, смена конфигураций.
🔸Feature Flags
Включение/отключение фич на лету.
Когда использовать — эксперименты, переключатели.
Типичные проблемы — A/B тесты, скрытые релизы.
🔸Стратегия миграции схемы
Обратная/прямая совместимость.
Когда использовать — миграция без простоя БД.
Типичные проблемы — expand-migrate-contract.
🔸Распределённые блокировки / выбор лидера
Координация одного активного воркера.
Когда использовать — уникальность cron, шардовое владение.
Типичные проблемы — один консумер, лидер партиции.
🔸Наблюдаемость (логи/метрики/трейсы)
Понимание, что делает система.
Когда использовать — SLO, отладка, планирование.
Типичные проблемы — задержка p99, error budget.
🔸Безопасность: AuthN/AuthZ
Проверка личности и прав доступа.
Когда использовать — мультиарендные продукты, внешние API.
Типичные проблемы — OAuth2/OIDC, RBAC/ABAC.
🔸Мультиарендность (pool/bridge/isolated)
Уровни изоляции данных и ресурсов.
Когда использовать — SaaS с множеством клиентов.
Типичные проблемы — отдельные БД на арендатора vs общая схема.
🔸Edge Compute/функции
Запуск логики ближе к пользователю.
Когда использовать — низкая задержка, лёгкие задачи.
Типичные проблемы — персонализация на краю, A/B тесты.
🔸Rate-Aware DB Patterns
Пакетная, очередная, троттлинг у БД.
Когда использовать — горячие партиции, блокировки.
Типичные проблемы — массовый импорт, ID hotspot.
🔸Стратегии пагинации
Keyset > Offset для больших данных.
Когда использовать — бесконечный скролл, большие таблицы.
Типичные проблемы — пагинация фидов, списки в админке.
👉 @BackendPortal
ChatGPT 5 — страшное оружие в умелых руках
Российский разработчик Олег Миллер, занимающий обучением и тренировкой новой модели Open AI в Сан-Франциско, рассказывает в своём блоге:
• Как отключить цензуру у ChatGPT (инструкция)
• Малоизвестные ИИ, с которыми вы станете богатым
• Почему человечество обречено на катастрофу из-за развития ИИ
За такие инсайды он может быть уволен. Поэтому блог закрытый, а ссылка на него постоянно меняется. Успей вступить: /channel/+l0m6bHg7b94xZGE6
Шпаргалка по основам распределенных систем
🔸Теорема CAP
Нельзя одновременно иметь Consistency, Availability и Partition tolerance
Используется при выборе компромиссов в распределённых БД
Примеры: CP — Zookeeper, AP — Cassandra
🔸Модели согласованности
Strong, Eventual, Causal, Read-your-writes
Применяются при выборе между задержкой и корректностью
Примеры: счётчик лайков vs банковский баланс
🔸Выбор лидера
Выбор одного координатора
Используется для управления кластером и владения партициями
Примеры: ZooKeeper, Raft
🔸Алгоритмы консенсуса
Достижение согласия о значении между нодами
Применяются для обновлений конфигурации и упорядочивания событий
Примеры: Raft, Paxos, Viewstamped Replication
🔸Чтения/записи с кворумом
Требуется подтверждение большинства
Используется для баланса между задержкой и согласованностью
Примеры: базы данных в стиле Dynamo
🔸Партиционирование / шардирование
Разделение данных или работы между нодами
Применяется для масштабирования за пределы одной машины
Примеры: шардирование по user-id, гео-шарды
🔸Репликация (синхронная/асинхронная)
Хранение нескольких копий данных
Используется для высокой доступности и низкой задержки чтения
Примеры: реплики MySQL, Kafka ISR
🔸Протокол Gossip
P2P-распространение состояния
Применяется в больших кластерах и для обнаружения сбоев
Пример: членство нод в Cassandra
🔸Векторные часы
Отслеживание причинного порядка событий
Используется для разрешения конфликтов
Пример: разрешение конфликтов в Dynamo
🔸Метки времени Лампорта
Логический порядок событий
Применяется в распределённом логировании и упорядочивании
Пример: Total order broadcast
🔸Семантика доставки сообщений
At-most-once, At-least-once, Exactly-once
Используется для надёжной обработки событий
Примеры: Kafka consumers, отправка email
🔸Ключи идемпотентности
Предотвращение дублирующих эффектов
Применяются при повторах в ненадёжных сетях
Примеры: обработка платежей, повтор задач
🔸Обработка eventual consistency
Разрешает временное чтение устаревших данных
Используется для низкой задержки и гео-репликации
Примеры: DNS-записи, социальные ленты
🔸Распределённая блокировка
Один активный владелец на всех нодах
Применяется для задач лидера и cron-задач
Примеры: Redis Redlock, ZK locks
👉 @BackendPortal
Это схема-шаблон для проектирования архитектуры сложных распределённых систем
Она показывает, как обычно строятся крупные веб-сервисы с микросервисной архитектурой и распределённой обработкой данных.
👉 @BackendPortal
Хочешь расти в разработке и делать проекты, а не просто "писать код"?
В моём Telegram-канале — честно и по делу:
— Как устроены технологии под капотом
— Как прокачиваться и выходить на уровень выше
— Мой опыт как разработчика и инженера: код, архитектура, фейлы, найм и запуски собственных проектов
Ни воды, ни мотивационных лозунгов — только реальный опыт, который редко встретишь в статьях.
Несколько постов, с которых можно начать:
— 👉Что нужно знать программисту кроме ЯП
— 👉 Как правильно собеседовать джунов
— 👉 Бывший работодатель хотел вернуть деньги
— 👉 Когда проект затянулся на полгода. И сожрал нервы.
— 👉 Делаю свой веб-фреймворк на C# с нуля (4.5 часа видео)
Если тебе близка такая подача — подписывайся. Увидимся там:
👨💻 @ruslan_shishmarev
Liam ERD
Это опенсорсный инструмент, который мгновенно генерирует красивые, интерактивные ER-диаграммы из существующих баз данных
Просто загружаете схему, и получаете понятные визуализации, где можно удобно смотреть связи, приближать, фильтровать и быстро разбираться даже с суперсложными структурами.
И всё это бесплатно и без необходимости регистрации. Инструкция на GitHub, ссылка на сервис.
👉 @BackendPortal
Свежий релиз для гоферов: вышел Go 1.25.0!
- Release notes: https://go.dev/doc/go1.25
- Скачать: https://go.dev/dl/#go1.25.0
Официальные примечания к релизу довольно сухие, поэтому откопал интерактивную версию с множеством примеров, показывающих, что изменилось и как теперь работает новый функционал. Читайте здесь
@IT_Portal
👩💻 В сеть вывалилась гигантская куча курсов и книг
Держи сотни гигабайт свежих уроков, и каждую неделю мы подкидываем ещё!
1402 ГБ — Python
1815 ГБ — Frontend
1515 ГБ — Backend
1300 ГБ — C / C++
694 ГБ — Java
546 ГБ — SQL & БД
411 ГБ — DevOps
898 ГБ — ИБ & Хакинг
212 ГБ — JavaScript
996 ГБ — Kotlin / Swift
173 ГБ — PHP
215 ГБ — GoLang
185 ГБ — Rust
517 ГБ — Linux
115 ГБ — QA / Тестирование
419 ГБ — GameDev
319 ГБ — 1C + Лицензии
617 ГБ — Машинное обучение
687 ГБ — Аналитика Данных
998 ГБ — Дизайн
Подписывайся и не плати за то, что можно получить бесплатно
Каждый повторный запрос к LLM — это деньги на ветер
Обычный кеш тут почти бесполезен, если промпт не совпадает один в один
Redis 8 меняет правила игры — теперь есть семантический кеш, который понимает смысл, а не просто ключи
LangCache + Vector Sets + Redis Flex = быстрее, дешевле, умнее
Полный разбор тут 👇
https://newsletter.systemdesignclassroom.com/p/every-repeated-llm-call-is-money-on-fire
👉 @BackendPortal
OpenObserve — облачная платформа для наблюдаемости, созданная специально для работы с логами, метриками, трейcами, аналитикой и RUM (производительность, ошибки, воспроизведение сессий), спроектированная для обработки данных в масштабе петабайт.
➤ https://github.com/openobserve/openobserve
👉 @BackendPortal
Обязательные принципы проектирования solution architecture
(объяснение за 2 минуты или меньше)
7 ключевых принципов с практическими рекомендациями по проектированию решений
🔸Высокая доступность и устойчивость
↳ Высокая доступность гарантирует работу системы даже при сбоях, а устойчивость — быстрое восстановление.
↳ Используй active-passive или active-active failover, чтобы минимизировать простой. Закладывай избыточность и синхронизацию данных там, где нужно, чтобы сохранить работу сервиса при сбоях.
🔸Масштабируемость
↳ Система должна справляться с ростом нагрузки без падения производительности.
↳ Вертикальное масштабирование — добавление ресурсов в узел, но горизонтальное (добавление узлов) с балансировкой нагрузки даёт больше гибкости. Используй авто-масштабирование и управление состоянием (например, распределённые кэши), чтобы эффективно переживать пиковые нагрузки.
🔸Производительность
↳ Оптимизация производительности снижает задержки и повышает пропускную способность.
↳ Применяй non-blocking I/O, асинхронную обработку и кэширование для работы с конкурентными запросами. Используй p99 latency метрики для мониторинга худших сценариев и поддержания стабильного UX.
🔸Безопасность
↳ Безопасность должна быть встроена на всех этапах. Реализуй end-to-end шифрование, RBAC и threat modelling для проактивного снижения рисков. Используй OAuth2 или JWT для аутентификации, а также подход Zero Trust Architecture для постоянной проверки идентичности.
🔸Слабая связанность
↳ Модульные системы легче масштабировать и адаптировать.
↳ Используй event-driven архитектуру и асинхронные очереди (например, Kafka, RabbitMQ), чтобы разорвать жёсткие зависимости. Это повысит масштабируемость, отказоустойчивость и облегчит обновления.
🔸Расширяемость
↳ Системы должны безболезненно расти со временем.
↳ Следуй принципу open-closed, чтобы добавлять новые фичи без изменения базовой логики. Проектируй API-first и сохраняй обратную совместимость, чтобы поддерживать интеграции без сбоев.
🔸Повторное использование
↳ Переиспользуемые компоненты ускоряют разработку и повышают поддерживаемость.
↳ Думай о компонуемости, используй общие библиотеки, SDK и готовые компоненты. Применяй domain-driven design (DDD), чтобы переиспользовать решения в разных бизнес-доменах.
Следуя этим принципам, можно строить системы, которые соответствуют текущим требованиям и остаются гибкими для будущих вызовов. Продуманная архитектура обеспечивает масштабируемость, безопасность и устойчивость, поддерживая постоянные инновации.
👉 @BackendPortal
Качество кода не появляется случайно.
Моменты, которые навсегда определили стандарты качества кода:
1987 – Принцип подстановки Лисков
Подтипы должны корректно работать везде, где ожидаются их родительские типы.
1988 – Принцип открытости/закрытости
Код должен легко расширяться без изменения уже существующего поведения.
1994 – Паттерны проектирования "Банда четырёх"
Общий словарь и проверенные структуры для решения типовых задач проектирования.
1999 – Рефакторинг
Книга Мартина Фаулера формализовала безопасное изменение кода как отдельную дисциплину.
2000 – Принцип разделения интерфейсов
Интерфейсы должны быть небольшими, чтобы классы реализовывали только то, что реально используют.
2003 – Принцип единственной ответственности и принцип инверсии зависимостей
Одна причина для изменения модуля; зависимости строятся на абстракциях, а не на конкретных реализациях.
2004 – Акроним SOLID
Пять принципов проектирования объединены в единую, легко запоминающуюся концепцию.
2005 – Предметно-ориентированное проектирование
Моделирование кода в соответствии с реальной бизнес-логикой и границами домена.
2008 – Чистый код
Код должен быть простым для чтения, понятным для рассуждения и безопасным для изменения.
2011 – Twelve-Factor App
Чёткая методология для построения переносимых, масштабируемых облачных сервисов.
2014 – Reactive Manifesto
Современные системы должны быть отзывчивыми, устойчивыми, эластичными и событийно-ориентированными.
2017 – TypeScript
Статическая типизация добавляет структуру и безопасность в крупные JavaScript-кодовые базы.
2018 – Инженерные практики Google
Читаемость кода, чёткая передача намерений и содержательные code review стали стандартом по умолчанию.
2019 – Чистая архитектура
Разделение бизнес-логики и фреймворков с помощью чётких слоёв и границ. (впервые опубликовано в 2017)
2023 – AI-ассистенты для написания кода
Дизайн и понятность кода стали важнее, чем когда-либо: ИИ пишет код, люди формулируют замысел.
Каждый из этих моментов изменил понимание того, что значит «хороший» код.
Сохраните этот список. Покажите его своей команде.
Если для вас важна поддерживаемость кода, вы стоите на плечах этих идей.
👉 @BackendPortal
На платформе SourceCraft новые возможности для опенсорс разработчиков
Платформа поддерживает полный цикл разработки: от постановки задачи до деплоя в облаке. Внутри — широкий набор инструментов для автоматизации рутины, например, быстрая навигация по коду, гибкая система CI/CD, встроенный ассистент и интеграция с облаком.
В обновлении расширили систему рейтинга. Теперь оценивать репозитории можно не просто одной звездой, а по трехбалльной шкале. Это поможет авторам получать более детальный фидбек, а пользователям — легче находить качественные проекты.
Также добавили систему ачивок — платформа теперь автоматически отслеживает активность (коммиты, ревью, участие в обсуждениях) и награждает за это.
Последняя часть апдейта — запуск грантовой программы для важных и интересных опенсорс-проектов. Можно получить грант на 600 000 рублей в виде кредитов на облачные технологии Yandex Cloud. При выборе проекта смотрят на активность репозитория, пользу, план развития и, конечно, место в рейтинге на самой платформе.
Factory Method Pattern
Factory Method определяет интерфейс для создания объектов, но делегирует выбор конкретного класса наследникам.
Относится к группе Creational, которая решает задачи инстанцирования объектов или семейств связанных объектов.
🔸 Когда применять
Используй Factory Method, когда заранее неизвестно, с какими конкретными типами объектов будет работать код.
Подходит для фреймворков, где требуется поддержка пользовательских классов, или когда нужно предоставить библиотеку продуктов с единым интерфейсом.
🔸 Как реализовать
1. Создай абстрактный класс-создатель с абстрактным фабричным методом
2. Конкретные создатели переопределяют этот метод и возвращают разные типы продуктов
3. Главная задача создателя — не просто создание объектов, а реализация бизнес-логики, которая зависит от этих продуктов
Паттерн выносит код создания объектов в одно место, упрощая поддержку.
Новые типы продуктов можно добавлять без изменения клиентского кода.
🔸 Почему это работает
- Нет жёсткой связки между создателем и конкретными продуктами
- Single Responsibility Principle — код создания вынесен отдельно
- Open/Closed Principle — новые типы можно добавлять без изменения старого кода
🔸 Минусы
- Усложнение за счёт дополнительных классов-создателей
👉 @BackendPortal
Нашёл неплохую опенсорс тулзу — FossFLOW
Она позволяет строить наглядные 3D-диаграммы для архитектуры софта и инженерных систем. Интерфейс удобный, есть импорт и экспорт в JSON, а все данные сохраняются локально прямо в браузере.
Можно пользоваться прямо онлайн
- демо
А можно поднять у себя
- GitHub
👉 @BackendPortal
Согласны?
Если это real-time → WebSockets
Если это про масштаб → Kafka
Если нужна простота → REST
Если нужен хаос → GraphQL
Если это про AI → Python
Если про инфраструктуру → Go
Если про логи → ElasticSearch
Если нужна низкая задержка → Redis
Если нужна высокая доступность → Postgres
Если это стриминг → Flink
Архитектура Stack Overflow — это не то, что вы думаете
В интервью со Скоттом Хансельманом Роберта Арковерде, руководитель инженерного отдела Stack Overflow, рассказала об архитектуре проекта.
Они обрабатывают более 6000 запросов в секунду, 2 миллиарда просмотров страниц в месяц и рендерят страницу примерно за 12 миллисекунд.
Можно было бы предположить, что у них микросервисное решение в облаке с Kubernetes. Но реальность другая. Их решение работает уже 15 лет и это большой монолит, развёрнутый on-premises.
Это по сути одно приложение на IIS, которое обслуживает 200 сайтов. Оно крутится на девяти веб-серверах и одном SQL Server (плюс один горячий standby).
Используется двухуровневое кеширование: первый уровень — на SQL Server с большой RAM (1.5 ТБ), где 30% обращений к БД обслуживаются из памяти, второй — два сервера Redis (master и реплика).
Дополнительно есть 3 сервера с tag-движком и 3 сервера Elastic Search для 34 миллионов поисковых запросов в день.
Всё это обслуживает команда из 50 инженеров, которые могут выкатывать код в прод за 4 минуты и делают это несколько раз в день.
Полный tech-stack:
C# + ASP.NET MVC
Dapper ORM
StackExchange Redis
MiniProfiler
Jil JSON Deserializer
Exceptional (логирование для SQL)
Sigil — генерация .NET CIL (когда C# недостаточно быстрый)
NetGain — высокопроизводительный WebSocket-сервер
Opserver — дашборд мониторинга с данными от Orion, Bosun или WMI
Bosun — backend-система мониторинга на Go
27 августа встречаемся на DrinkUp от Авито для backend-разработчиков в Нижнем Новгороде. Уже предчувствуем горячие споры… ☄️
В планах в формате дискуссий обсудить:
➡️ как правильно структурировать проекты;
➡️ кому и как проще вкатиться в Go и почему он такой странный;
➡️ как LLM помогает разработчикам.
Остальные темы раскрывать не будем — можете посмотреть их по ссылке! Там же, кстати, и регистрация на ивент.
Как обрабатывать 1K одновременных загрузок/скачиваний файлов
1. Используй Object Storage (а не свой бэкенд)
Проблема
CPU и память сервера приложения забиваются под завязку
Решение
- Использовать S3, GCS, Azure Blob — хранилища, заточенные под высокий I/O
2. Используй Presigned URLs
Проблема
Маршрутизация всех загрузок/скачиваний через бэкенд = медленно и дорого
Решение
- Генерировать presigned URL на бэкенде
- Пусть клиент грузит/скачивает напрямую в/из хранилища
3. Дроби на чанки и загружай параллельно
Проблема
Большие файлы висят или падают по таймауту
Решение
- Делить на чанки по 5–10 МБ
- Грузить параллельно через multipart upload (в S3 есть нативно)
4. Асинхронная пост-обработка
Проблема
Обработка (антивирус, сжатие и т.д.) тормозит всё
Решение
- Принимать файл → сразу отдавать 202
- Обрабатывать в фоне через очередь (SQS, RabbitMQ)
5. Контролируй конкурентность
Проблема
Слишком много одновременных загрузок = I/O умирает
Решение
- Лимитировать число загрузок на пользователя
- Использовать backpressure или очередь на клиенте/в браузере
6. Используй CDN для скачиваний
Проблема
Пики трафика на скачивание нагружают origin
Решение
- Кэшировать файлы на edge через CDN (Cloudflare, Akamai, CloudFront)
- Раздавать пользователю с минимальной задержкой
👉 @BackendPortal
Теория графов в реальном мире
🔸LinkedIn: Люди, которых вы можете знать
Каждый профиль — это узел. Каждая связь — это ребро.
Система проходит по этой сети с помощью обхода графа, чтобы предложить связи второй степени.
Ты здесь не просто просматриваешь — тебя обходят. Обход графа: поиск в ширину / поиск в глубину для поиска связей
🔸Uber: Сопоставление пассажиров и водителей
Пассажиры с одной стороны, водители с другой — получается двудольный граф.
Сопоставление происходит через алгоритмы, решающие задачу максимального паросочетания.
Это не магия — это математика. Алгоритм Венгера для оптимального сопоставления
🔸Google Maps: Самый быстрый маршрут
Каждый перекрёсток — это узел. Каждая дорога — это ребро с весом (время в пути).
Карты используют алгоритм Дейкстры или A* для поиска кратчайшего пути.
Этот «самый быстрый маршрут» считается за миллисекунды. Алгоритм Дейкстры + A* с эвристическим поиском
🔸Instagram: Лента рекомендаций
Пользователи и посты образуют огромный граф.
Встраивания графа превращают этот хаос в математическую модель, чтобы находить паттерны и рекомендовать контент.
То, что кажется «открытием», на самом деле — близость в пространстве графа. Node2Vec, GraphSAGE для встраиваний
🔸Git: История коммитов
Твой репозиторий — это не просто таймлайн. Это направленный ацикличный граф.
Каждый коммит указывает на родителя или родителей, позволяя ветвление, слияния и переписывание истории.
Поэтому Git мощный… и иногда пугающий. Структура направленного ацикличного графа для контроля версий
🔸Netflix: Рекомендательный движок
Пользователи, фильмы и история просмотров образуют многослойный граф.
Коллаборативная фильтрация ищет похожих пользователей и советует контент на основе кластеризации графа.
Твой следующий сериал предсказывается графовыми алгоритмами. Факторизация матриц + кластеризация графа
🔸Facebook: Ранжирование новостной ленты
Посты, пользователи, лайки и репосты формируют социальный граф.
Алгоритмы, похожие на PageRank, определяют, что попадёт в ленту, исходя из соцсвязей и вовлечённости.
Твоя лента формируется на основе мер центральности графа. EdgeRank + анализ социального графа
🔸Amazon: Рекомендации товаров
Товары, клиенты и история покупок образуют двудольный граф.
Алгоритмы случайных блужданий и графовые нейросети ищут «клиентов, которые купили это, также купили…».
Каждое «рекомендуем для вас» — это путь в графе товаров. Случайное блуждание + графовые нейронные сети
👉 @BackendPortal
Яндекс создаёт продукты и сервисы для миллионов пользователей. Нейросетевой поиск, умные устройства, машинный перевод — задачи, где нет готовых решений.
Поэтому нам нужны сильные бэкенд-разработчики! Если у вас от 5 лет опыта на C++, Python, Java или Go — участвуйте в Мультитреке.
Как это работает
• Подаёте заявку до 18 августа
• Проходите технические секции 23 и 24 августа
• Получаете офер 24 августа
После найма мы предложим поработать в трёх командах несколько недель. Будет время погрузиться в работу, прочувствовать атмосферу и выбрать проект, который вам больше подходит.
Узнайте подробности и оставьте заявку.
Если вы использовали slog, Uber Zap, Logrus, Zerolog и другие библиотеки для структурированного логирования, прочитайте эту статью: https://victoriametrics.com/blog/victorialogs-concepts-message-time-stream/
чтобы узнать лучшие практики, которые не только помогут вашей команде быстрее разбираться в проблемах, но и упростят жизнь вашим DevOps
👉 @BackendPortal
Разные способы обрабатывать загрузку файлов
🔸POST на сервер приложения
Пользователь отправляет файл прямо на твой сервер, как при обычной отправке формы
Приложение получает файл через multipart/form-data и сохраняет его
Плюсы
✓ Простая аутентификация и контроль
Минусы
✗ Канал и CPU сервера становятся узким местом
🔸Загрузка напрямую в хранилище через Pre-Signed URL
Приложение выдает клиенту разрешение на загрузку прямо в облачное хранилище
Сервер генерирует подписанный URL, клиент грузит в S3/GCS
Плюсы
✓ Снимает трафик с сервера, масштабируется
Минусы
✗ Нужно отдельно получать URL, аккуратнее с CORS
🔸Поштучная / возобновляемая загрузка (Chunked / Resumable)
Разбиваем большие файлы на куски и перезагружаем только те, что не дошли
Например: S3 Multipart, tus.io
Плюсы
✓ Живёт в условиях плохих сетей, поддерживает огромные файлы
Минусы
✗ Требует больше координации между клиентом и сервером
🔸Потоковая загрузка на бэкенд
Обрабатываем данные файла по мере поступления, не дожидаясь конца загрузки
Поток сразу идет в хранилище или обработчик
Плюсы
✓ Минимальный расход памяти, удобна для backpressure
Минусы
✗ Сложнее обрабатывать частичные ошибки и делать частичную очистку
🔸Асинхронная обработка
Принимаем файл быстро, а потом обрабатываем в фоне
Загрузка → очередь → воркер (скан, транскод, и т.д.)
Плюсы
✓ Быстрые ACK, тяжёлая обработка изолирована
Минусы
✗ Нужна инфраструктура (очереди, воркеры) и трекинг статуса
🔸Загрузка через edge/proxy
Загрузка идёт на edge-локации CDN, ближе к пользователям
CDN-воркер или gateway принимает загрузку и шлёт в хранилище
Плюсы
✓ Ближе к пользователям, защищает origin
Минусы
✗ Лимиты платформы, сложнее дебажить
🔸Пакетная загрузка / SFTP
Партнёры грузят большие файлы в защищенную папку по расписанию
Файлы падают в управляемый инбокс (Enterprise)
Плюсы
✓ Работает для больших и плановых передач
Минусы
✗ Высокая задержка, операционные накладные, управление ключами
Правила на заметку
> Малые и средние файлы — прямая загрузка в хранилище через pre-signed URLs
> Огромные файлы или нестабильные сети — chunked/resumable uploads
> Сильная пост-обработка — асинхронная обработка с воркерами
> Глобальные пользователи — edge-proxy с объектным хранилищем
👉 @BackendPortal
Поздравляем, вы на 1 шаг ближе к работе мечты 🥳
Осталось только прочитать этот пост, подписаться на канал и откликнуться на вакансию 😉
Avito Career — место, где Авито делится актуальными вакансиями и стажировками для бэкенд-разработчиков.
Подписывайтесь, чтобы найти ту самую работу ✨
Шардинг баз данных все что нужно знать
1. Что такое шардинг
Делим большую базу на несколько частей чтобы масштабироваться по горизонтали. Полезно когда одна БД уже не тянет чтение запись или хранение например миллионы юзерских записей.
2. Шард это кусок данных
Каждый шард это полноценная независимая БД которая держит часть общего набора. Пример пользователи с id 1..1M в шарде A и 1M..2M в шарде B.
3. Ключ шарда
Поле по которому решаем где хранить запись. Выбор ключа критичен для баланса и перфа. Пример user_id для базы пользователей.
4. Горизонтальное партиционирование
По сути то же что шардинг. Режем по строкам а не по колонкам. Пример клиентские данные по регионам US EU Asia.
5. Виды шардинга
Range based диапазоны id например 1..1M в одном шарде 1M..2M в следующем просто но есть риск хотспотов.
Hash based хеш функция распределяет записи по шардам убирает хотспоты но сложнее запрашивать диапазоны.
Geo based делим по географии даем локальным юзерам низкую задержку.
6. Карта шардов и роутинг
Сервис который знает в каком шарде живет запись. Пример таблица соответствий user_id и shard_host.
7. Решардинг
Меняем распределение данных когда шарды растут неравномерно или добавляем ноды. Без планирования боль возможен даунтайм и большие перетасовки данных.
8. Репликация в шардированной схеме
У каждого шарда все равно должны быть реплики для отказоустойчивости. Пример шард A имеет primary плюс две реплики для HA.
9. Когда стоит применять шардинг
Размер БД больше чем влезает на один сервер.
Запись стала узким местом.
Нужна низкая задержка в нескольких регионах.
10. Когда лучше не шардинговать
БД спокойно помещается на одной ноде.
Чтение можно масштабировать репликами.
Запросы часто требуют джоинов между шардами.
Очень хорошая схема, суммирующая архитектуру Kubernetes
С точки зрения интервью, как минимум ты должен уметь объяснить каждый компонент в ней
👉 @BackendPortal
Онлайн-система приёма платежей (Paypal/Stripe)
🔸Цели и требования
100M+ пользователей кошелька
1B+ транзакций в год
$500B+ объём платежей
99.99% точность
Ключевые фичи:
- Цифровой кошелёк для хранения средств
- P2P-переводы между пользователями
- Обработка платежей мерчантов
- Линк банковского счёта и карт
- Обработка возвратов и чарджбеков
- Соответствие KYC/AML
- Система разрешения споров
🔸Архитектура высокого уровня
Auth & KYC Service — онбординг пользователей, верификация личности.
Wallet & Ledger Service — двойная бухгалтерия, управление балансами.
Payments Orchestrator — маршрутизация в карточные и банковские сети.
Risk/Fraud Engine — реал-тайм детект мошенничества.
Disputes Service — управление чарджбеками.
Payouts Service — выплаты мерчантам.
Compliance & Reporting — AML-мониторинг, аудит логов.
Примеры двойной бухгалтерии:
P2P-перевод (₹100):
Дебет: кошелёк отправителя ₹100
Кредит: кошелёк получателя ₹100
Оплата мерчанту (₹100, комиссия ₹2):
Дебет: кошелёк покупателя ₹100
Кредит: кошелёк мерчанта ₹98
Кредит: счёт комиссий ₹2
🔸Высокоуровневый флоу
1. Онбординг и KYC
- Создать аккаунт с подтверждением email/телефона
- Верификация личности (ID, селфи, proof of address)
- Привязка банковского счёта или карты с микро-депозитами
- Оценка рисков и комплаенс-чек Sign up → Verify identity → Link payment method → Risk assessment
2. Пополнение кошелька
- Пользователь инициирует пополнение с привязанной карты/счёта
- Платёжный процессор делает внешний запрос
- При успехе — кредит кошелька пользователя
- Леджер обновляет баланс Charge card/bank → Verify funds → Credit wallet → Update ledger
3. P2P-перевод (атомарный)
- Проверка баланса отправителя
- Чек правил антифрода для обеих сторон
- Атомарная транзакция: дебет отправителя, кредит получателя
- Реал-тайм уведомления обеим сторонам Check balance → Risk validation → Atomic transfer → Notify users
4. Платёж мерчанту
- Авторизация платежа (заморозка в кошельке)
- При доставке — захват платежа
- Выплата на баланс мерчанта (минус комиссия)
- Пакетная выплата на банковский счёт мерчанта Authorize → Capture → Settle → Payout to merchant bank
5. Возврат/чарджбек
- Реверс исходных леджер-записей
- Корректировка балансов всех затронутых аккаунтов
- Работа с доказательной базой
- Автоматические уведомления и трекинг прогресса Dispute initiated → Reverse entries → Collect evidence → Resolve
🔸Data Model
users — id, kyc_status, risk_score.
accounts — id, owner_id, type, currency.
ledger_entries — txn_id, account_id, debit, credit.
transactions — id, amount, status, idempotency_key.
payment_methods — user_id, tokenized_card, bank_link.
disputes — txn_id, phase, deadline, evidence.
Критические индексы:
(txn_id) для поиска.
(account_id, timestamp) для балансов.
(idempotency_key) уникальный.
🔸Безопасность и комплаенс
Фрод-превеншн:
- Лимиты частоты операций per user/device
- ML-анализ аномалий
- Device fingerprinting
- Поведенческий анализ
Комплаенс:
- Верификация KYC/AML
- PCI-DSS для данных карт
- Мониторинг транзакций
- Аудит логов (WORM)
Резервное управление:
- Риск-базовые резервы под чарджбеки
- Автоматические корректировки
🔸Стратегия масштабирования
Масштабирование леджера:
- PostgreSQL с партиционированием
- Append-only для неизменяемости
- Реплики для запросов по балансу
Консистентность:
- Сильная консистентность для леджера
- Идемпотентность для защиты от дубликатов
- Асинхронная обработка уведомлений
Техстек:
- PostgreSQL (точная работа с десятичными)
- Go/Java-сервисы
- Redis для кеша
- Kafka для асинхронных процессов
👉 @BackendPortal