Как 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
Изучи эти 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 системы.
Хватит прыгать с одного языка на другой.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11👍5
Консистентность «read-your-writes» означает, что любая запись, сделанная в базу данных, сразу становится доступной для чтения тем же клиентом.
Звучит очевидно, но бывают ситуации, когда это правило не выполняется, особенно при работе на больших масштабах.
На сервере с одной нодой это легко гарантировать при использовании последовательных транзакций.
В среде с primary и replica всё сложнее. Во многих базах данных все записи и часть чтений обрабатываются на primary, а большая часть чтений выполняется на репликах. Из-за задержки репликации может возникнуть ситуация, когда клиент записывает данные в базу и тут же пытается их прочитать с реплики, но записи там ещё нет.
Такое возможно при использовании асинхронной или полусинхронной репликации, так как они не требуют, чтобы все реплики получили данные до ответа клиенту. При синхронной репликации primary отвечает только после того, как все реплики подтвердят получение записи.
Если используется асинхронная или полусинхронная репликация, чтения на реплики лучше направлять только тогда, когда консистентность «read-your-writes» не критична.
👉 @BackendPortal
Звучит очевидно, но бывают ситуации, когда это правило не выполняется, особенно при работе на больших масштабах.
На сервере с одной нодой это легко гарантировать при использовании последовательных транзакций.
В среде с primary и replica всё сложнее. Во многих базах данных все записи и часть чтений обрабатываются на primary, а большая часть чтений выполняется на репликах. Из-за задержки репликации может возникнуть ситуация, когда клиент записывает данные в базу и тут же пытается их прочитать с реплики, но записи там ещё нет.
Такое возможно при использовании асинхронной или полусинхронной репликации, так как они не требуют, чтобы все реплики получили данные до ответа клиенту. При синхронной репликации primary отвечает только после того, как все реплики подтвердят получение записи.
Если используется асинхронная или полусинхронная репликация, чтения на реплики лучше направлять только тогда, когда консистентность «read-your-writes» не критична.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
Кэшировать или не кэшировать?
Это вопрос, с которым бэкендер сталкивается каждый день.
Большинство инженеров кэшируют слишком много.
Это ленивая инженерия.
Вот небольшой фреймворк, чтобы принимать решение правильно:
I. Данные часто запрашиваются?
II. Их дорого получать?
III. Они изменчивые?
IV. Объём данных большой?
V. Влияет ли это на воспринимаемую пользователем задержку?
VI. Безопасно ли кэшировать?
VII. Есть ли механизм протухания или инвалидации кэша?
👉 @BackendPortal
Это вопрос, с которым бэкендер сталкивается каждый день.
Большинство инженеров кэшируют слишком много.
Это ленивая инженерия.
Вот небольшой фреймворк, чтобы принимать решение правильно:
I. Данные часто запрашиваются?
II. Их дорого получать?
III. Они изменчивые?
IV. Объём данных большой?
V. Влияет ли это на воспринимаемую пользователем задержку?
VI. Безопасно ли кэшировать?
VII. Есть ли механизм протухания или инвалидации кэша?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤3
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Суперпонятные гайды по программированию: ООП, Docker, Kubernetes, Git, OAuth — всё объясняется на примере милых котиков! 🐱
👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11❤8🔥2
Бесплатный прирост производительности для full table scan в Postgres 17
Смотри, Postgres как и большинство баз данных работает с фиксированными по размеру страницами. В таком формате хранится всё, включая индексы и данные таблиц. Размер страницы 8КБ, каждая страница содержит строки или индексные кортежи плюс фиксированный заголовок. По сути, страницы это просто байты в файлах, которые читаются и кешируются в buffer pool.
Например, чтобы прочитать страницу 0, вызывается read с offset 0 и длиной 8192 байта. Чтобы прочитать страницу 1, выполняется ещё один системный вызов read с offset 8193 и длиной 8192. Страница 7 это уже offset 57 345 и так далее.
Если таблица занимает 100 страниц в файле, то для full table scan мы сделаем 100 системных вызовов. У каждого вызова есть накладные расходы
Фича в Postgres 17 в том, что теперь можно объединять I/O. Можно задать, сколько операций объединять. Технически можно просканировать всю таблицу за один системный вызов. Это не всегда хорошая идея, и я ещё расскажу почему.
Также здесь добавили vectorized I/O с помощью системного вызова preadv, который принимает массив офсетов и длин для рандомных чтений.
Основная сложность это не читать лишнего. Допустим, я делаю seq scan и ищу конкретное значение. Я читаю страницу 0, нахожу результат и выхожу. Дальше читать не нужно. А с этой фичей я могу прочитать сразу 10 страниц за один вызов, вытащить их содержимое в shared buffers и только потом обнаружить, что результат был уже на первой странице. В итоге я зря потратил диск, память и пропускную способность.
Балансировать это будет непросто.
Важно понимать, что настоящий Postgres делает системный вызов в ядро, чтобы прочитать по 8К за раз. При этом ядро можно настроить на read ahead. В этом случае оно будет читать немного больше и кешировать данные в файловом кеше.
👉 @BackendPortal
Смотри, Postgres как и большинство баз данных работает с фиксированными по размеру страницами. В таком формате хранится всё, включая индексы и данные таблиц. Размер страницы 8КБ, каждая страница содержит строки или индексные кортежи плюс фиксированный заголовок. По сути, страницы это просто байты в файлах, которые читаются и кешируются в buffer pool.
Например, чтобы прочитать страницу 0, вызывается read с offset 0 и длиной 8192 байта. Чтобы прочитать страницу 1, выполняется ещё один системный вызов read с offset 8193 и длиной 8192. Страница 7 это уже offset 57 345 и так далее.
Если таблица занимает 100 страниц в файле, то для full table scan мы сделаем 100 системных вызовов. У каждого вызова есть накладные расходы
Фича в Postgres 17 в том, что теперь можно объединять I/O. Можно задать, сколько операций объединять. Технически можно просканировать всю таблицу за один системный вызов. Это не всегда хорошая идея, и я ещё расскажу почему.
Также здесь добавили vectorized I/O с помощью системного вызова preadv, который принимает массив офсетов и длин для рандомных чтений.
Основная сложность это не читать лишнего. Допустим, я делаю seq scan и ищу конкретное значение. Я читаю страницу 0, нахожу результат и выхожу. Дальше читать не нужно. А с этой фичей я могу прочитать сразу 10 страниц за один вызов, вытащить их содержимое в shared buffers и только потом обнаружить, что результат был уже на первой странице. В итоге я зря потратил диск, память и пропускную способность.
Балансировать это будет непросто.
Важно понимать, что настоящий Postgres делает системный вызов в ядро, чтобы прочитать по 8К за раз. При этом ядро можно настроить на read ahead. В этом случае оно будет читать немного больше и кешировать данные в файловом кеше.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍3
Ваша софтверная архитектура всегда так же сложна, как и ваша организация
Слышали про Закон Конвея? Это теория, сформулированная компьютерным учёным Мелвином Конвеем в 1967 году. Она гласит:
Другими словами, структура софтверной системы часто определяется структурой и паттернами коммуникации внутри команды, которая её разрабатывает.
Из-за этого архитектура может оказаться неоптимальной для решаемой задачи — команда невольно начинает ставить свои организационные ограничения выше потребностей системы.
Например:
- организация с небольшими распределёнными командами скорее всего придёт к модульной (сервисной) архитектуре,
- а организация с крупными коллокированными командами — к монолитной архитектуре.
В широком смысле можно даже сказать, что именно HR во многом определяет архитектуру софта.🤙
Чтобы обойти это ограничение, используют манёвр обратного Конвея (Inverse Conway Maneuver). Суть его в том, что архитекторы, инженеры и лиды вовлекаются в проектирование организационной структуры. Такой подход повышает шансы на более удачную архитектуру.
Тем не менее, многие компании игнорируют закон Конвея и живут в уверенности, что оргструктура и архитектура системы — вещи независимые. В итоге это оборачивается неприятными сюрпризами.
А теперь к вам, каков ваш опыт столкновения с Законом Конвея?👧
👉 @BackendPortal
Слышали про Закон Конвея? Это теория, сформулированная компьютерным учёным Мелвином Конвеем в 1967 году. Она гласит:
«Организации, которые проектируют системы, ограничены в своих возможностях создавать дизайны, являющиеся копиями их собственных коммуникационных структур».
Другими словами, структура софтверной системы часто определяется структурой и паттернами коммуникации внутри команды, которая её разрабатывает.
Из-за этого архитектура может оказаться неоптимальной для решаемой задачи — команда невольно начинает ставить свои организационные ограничения выше потребностей системы.
Например:
- организация с небольшими распределёнными командами скорее всего придёт к модульной (сервисной) архитектуре,
- а организация с крупными коллокированными командами — к монолитной архитектуре.
В широком смысле можно даже сказать, что именно HR во многом определяет архитектуру софта.
Чтобы обойти это ограничение, используют манёвр обратного Конвея (Inverse Conway Maneuver). Суть его в том, что архитекторы, инженеры и лиды вовлекаются в проектирование организационной структуры. Такой подход повышает шансы на более удачную архитектуру.
Тем не менее, многие компании игнорируют закон Конвея и живут в уверенности, что оргструктура и архитектура системы — вещи независимые. В итоге это оборачивается неприятными сюрпризами.
А теперь к вам, каков ваш опыт столкновения с Законом Конвея?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10👍4
Концепции API, которые обсуждают на собеседованиях, не пропускай, если ты backend-разработчик:
I. Идемпотентность: понимайте, почему PUT/DELETE идемпотентны, а POST — нет. Это помогает избегать случайных двойных записей.
II. Пагинация: offset работает до определённого масштаба. Для больших наборов данных используйте курсор/ключи
III. Версионирование: URI vs Header vs Query param. Единственно правильного способа нет, есть только компромиссы.
IV. Ограничение частоты запросов: Token bucket лучше простой фиксированной временной окна, если важна справедливость.
V. Контракты ошибок: 400 ≠ 422 ≠ 409. Не кидайте 500 повсюду.
VI. Кэширование: ETag + Cache-Control спасают от лишней нагрузки на БД.
VII. Безопасность: JWT истекают не просто так. Не храните в них PII пользователей.
VIII. N+1 запросы: убивайте их на ранней стадии. Используйте batching или join’ы при возврате вложенных ресурсов.
IX. Документация: OpenAPI/Swagger обязателен.
X. Консистентность: иногда кэшированных данных хватает.
👉 @BackendPortal
I. Идемпотентность: понимайте, почему PUT/DELETE идемпотентны, а POST — нет. Это помогает избегать случайных двойных записей.
II. Пагинация: offset работает до определённого масштаба. Для больших наборов данных используйте курсор/ключи
III. Версионирование: URI vs Header vs Query param. Единственно правильного способа нет, есть только компромиссы.
IV. Ограничение частоты запросов: Token bucket лучше простой фиксированной временной окна, если важна справедливость.
V. Контракты ошибок: 400 ≠ 422 ≠ 409. Не кидайте 500 повсюду.
VI. Кэширование: ETag + Cache-Control спасают от лишней нагрузки на БД.
VII. Безопасность: JWT истекают не просто так. Не храните в них PII пользователей.
VIII. N+1 запросы: убивайте их на ранней стадии. Используйте batching или join’ы при возврате вложенных ресурсов.
IX. Документация: OpenAPI/Swagger обязателен.
X. Консистентность: иногда кэшированных данных хватает.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍4
Новая подборка open source веб-проектов, которые уже работают в продакшене. Проекты разделены по языкам и фреймворкам: Python/Django, JS/NextJS, Go, PHP и другие.
Можно не только изучать кодовую базу, но и участвовать -> делать баг-репорты, пулл-реквесты или просто смотреть, как устроена архитектура, структура каталогов, CI/CD и другие процессы.
Отличный способ прокачать навыки и посмотреть, как реальные проекты живут в продакшене.👩💻
👉 @BackendPortal
Можно не только изучать кодовую базу, но и участвовать -> делать баг-репорты, пулл-реквесты или просто смотреть, как устроена архитектура, структура каталогов, CI/CD и другие процессы.
Отличный способ прокачать навыки и посмотреть, как реальные проекты живут в продакшене.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍2
Как Discord тянет миллион онлайна на одном сервере
По мере роста аудитории Discord отдельные сервера начали упираться в лимиты по пропускной способности и отклику. Нужно было масштабировать их не с десятков тысяч, а сразу до миллионов одновременных пользователей.
Каждое действие в чате вроде отправки сообщения или входа в канал требует обновления UI у всех онлайн. Внутри Discord сервер называется guild и работает в одном Elixir процессе. Отдельный процесс это session для каждого клиента. Guild хранит все сессии участников и управляет их действиями. Обновления из сессий отправляются через вебсокеты клиентам.
Главная проблема это одно сообщение должно улететь всем онлайн. Если на сервере тысяча человек и каждый напишет по сообщению получится миллион доставок.
Как они это решили
1. Passive sessions
Discord стал различать активные и пассивные соединения. Для пассивных клиентов обновления режутся до минимума. Это снизило нагрузку на fanout почти на 90 процентов в больших серверах.
2. Relays
Ввели систему relay что-то вроде многопоточности на уровне инфраструктуры. Fanout теперь распределяется по нескольким машинам. Guild держит только базовую логику а relay процессы подключаются к сессиям, проверяют права и рассылают данные.
3. Worker процессы и ETS
Чтобы не блокировать guild процесс тяжелые операции вынесли в отдельные воркеры. Для работы с огромными списками участников они используют ETS (Erlang Term Storage) быструю in-memory базу к которой безопасно обращаются сразу несколько процессов. Guild создаёт воркер, передаёт ему таблицу ETS и тот делает всю дорогую работу.
В результате логика распределена, нагрузка размазана по воркерам и релеям, данные отправляются только активным пользователям. Всё это вместе позволяет держать миллион и больше онлайна на одном сервере.
👉 @BackendPortal
По мере роста аудитории Discord отдельные сервера начали упираться в лимиты по пропускной способности и отклику. Нужно было масштабировать их не с десятков тысяч, а сразу до миллионов одновременных пользователей.
Каждое действие в чате вроде отправки сообщения или входа в канал требует обновления UI у всех онлайн. Внутри Discord сервер называется guild и работает в одном Elixir процессе. Отдельный процесс это session для каждого клиента. Guild хранит все сессии участников и управляет их действиями. Обновления из сессий отправляются через вебсокеты клиентам.
Главная проблема это одно сообщение должно улететь всем онлайн. Если на сервере тысяча человек и каждый напишет по сообщению получится миллион доставок.
Как они это решили
1. Passive sessions
Discord стал различать активные и пассивные соединения. Для пассивных клиентов обновления режутся до минимума. Это снизило нагрузку на fanout почти на 90 процентов в больших серверах.
2. Relays
Ввели систему relay что-то вроде многопоточности на уровне инфраструктуры. Fanout теперь распределяется по нескольким машинам. Guild держит только базовую логику а relay процессы подключаются к сессиям, проверяют права и рассылают данные.
3. Worker процессы и ETS
Чтобы не блокировать guild процесс тяжелые операции вынесли в отдельные воркеры. Для работы с огромными списками участников они используют ETS (Erlang Term Storage) быструю in-memory базу к которой безопасно обращаются сразу несколько процессов. Guild создаёт воркер, передаёт ему таблицу ETS и тот делает всю дорогую работу.
В результате логика распределена, нагрузка размазана по воркерам и релеям, данные отправляются только активным пользователям. Всё это вместе позволяет держать миллион и больше онлайна на одном сервере.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤3
Как бэкенд-разработчик, рано или поздно ты поймёшь… дело не только в API и базах данных.
Всё сводится к тому, как системы общаются друг с другом на масштабе. Сможет ли твой сервис выдержать миллионы запросов без падений, выживет ли модель данных, когда продукт внезапно потребует десять новых фич, и сможет ли архитектура развиваться без проблем.
Настоящее веселье начинается, когда выходишь за рамки обычного CRUD
👉 @BackendPortal
Всё сводится к тому, как системы общаются друг с другом на масштабе. Сможет ли твой сервис выдержать миллионы запросов без падений, выживет ли модель данных, когда продукт внезапно потребует десять новых фич, и сможет ли архитектура развиваться без проблем.
Настоящее веселье начинается, когда выходишь за рамки обычного CRUD
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15❤11
Новая фишка для разработчиков данных
DataTUI — терминальный UI для работы с CSV, Excel, SQLite, Parquet и JSON. Сортировка, фильтры, SQL-запросы и мгновенный просмотр схемы прямо в терминале.
Написан на Rust, установка за пару минут.
GitHub: https://github.com/forensicmatt/datatui
👉 @BackendPortal
DataTUI — терминальный UI для работы с CSV, Excel, SQLite, Parquet и JSON. Сортировка, фильтры, SQL-запросы и мгновенный просмотр схемы прямо в терминале.
Написан на Rust, установка за пару минут.
GitHub: https://github.com/forensicmatt/datatui
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯5❤4
20 важных объектов/компонентов Kubernetes, которые обязательно нужно знать
👉 @BackendPortal
20. StatefulSet – Для приложений, которым нужны стабильный сетевой идентификатор и персистентное хранилище, например базы данных.
19. DaemonSet – Гарантирует запуск Pod на каждом (или выбранном) узле, часто используется для агентов логирования и мониторинга.
18. Job – Запускает Pod до успешного завершения задачи, идеально для batch-ворклоадов.
17. CronJob – Планирует Jobs с фиксированными интервалами, например бэкапы или отчётные задачи.
16. NetworkPolicy – Определяет, как Pods общаются между собой и с внешними сервисами, добавляя безопасность.
15. PersistentVolume (PV) – Ресурс хранилища на уровне кластера, предоставляемый админом или динамически через StorageClass.
14. PersistentVolumeClaim (PVC) – Запрос Pod на хранилище, который связывается с PV.
13. StorageClass – Определяет типы хранилища и позволяет динамически создавать тома.
12. HorizontalPodAutoscaler (HPA) – Автоматически масштабирует Pods по CPU, памяти или кастомным метрикам.
11. ResourceQuota – Устанавливает общие лимиты ресурсов (CPU, память, хранилище) на Namespace.
10. LimitRange – Задаёт минимальные и максимальные запросы и лимиты ресурсов для Pods или контейнеров.
9. Role & RoleBinding / ClusterRole & ClusterRoleBinding – Обеспечивают детальный контроль доступа через RBAC.
8. Ingress – Управляет внешним доступом к Services, обычно HTTP/HTTPS, с правилами маршрутизации и TLS.
7. ReplicaSet – Гарантирует, что указанное число реплик Pod всегда запущено.
6. Deployment – Декларативно управляет ReplicaSets для rolling update и масштабирования.
5. Service – Обеспечивает Pods стабильным IP/DNS и умеет балансировать трафик между ними.
4. Pod – Наименьшая единица в Kubernetes, обычно запускает один контейнер (или несколько тесно связанных).
3. ConfigMap – Хранит неконфиденциальные данные конфигурации в виде ключ-значение.
2. Secret – Хранит чувствительные данные (пароли, токены, сертификаты) в закодированном виде.
1. Namespace – Обеспечивает логическую изоляцию и организацию внутри кластера.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
Готовишься к бэкенд-собеседованиям?
Вот 5 концептов, о которых спрашивают почти всегда:
🔴 Connection Pooling
Держим пул готовых подключений к БД вместо открытия нового на каждый запрос. Экономит время и снижает нагрузку на базу.
🔴 Thread Pools & Async Processing
Пулы потоков переиспользуют фиксированное число потоков для выполнения задач. Асинхронная обработка позволяет не блокировать выполнение и обслуживать больше запросов одновременно.
🔴 Backpressure & Rate Limiting
Backpressure замедляет продюсеров, если консюмеры не успевают. Rate limiting ограничивает количество запросов, которое сервис принимает за единицу времени.
🔴 Load Shedding
При перегрузке система отбрасывает часть запросов, чтобы оставаться работоспособной и обрабатывать важные.
🔴 Circuit Breakers
Не даём системе бесконечно стучаться в падающий сервис: отключаем запросы на время, потом пробуем снова.
👉 @BackendPortal
Вот 5 концептов, о которых спрашивают почти всегда:
Держим пул готовых подключений к БД вместо открытия нового на каждый запрос. Экономит время и снижает нагрузку на базу.
Пулы потоков переиспользуют фиксированное число потоков для выполнения задач. Асинхронная обработка позволяет не блокировать выполнение и обслуживать больше запросов одновременно.
Backpressure замедляет продюсеров, если консюмеры не успевают. Rate limiting ограничивает количество запросов, которое сервис принимает за единицу времени.
При перегрузке система отбрасывает часть запросов, чтобы оставаться работоспособной и обрабатывать важные.
Не даём системе бесконечно стучаться в падающий сервис: отключаем запросы на время, потом пробуем снова.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
Reddit имеет более 504 млн пользователей и 91 млн активных в день.
Это безумный масштаб.
Но при миллиардах постов с изображениями GIF и видео Reddit столкнулся с серьёзной проблемой.
Эффективно хранить и отдавать метаданные медиа в масштабе.
С данными у Reddit не было проблем.
Проблема была в другом.
Метаданные медиа включая миниатюры, битрейты, URL для воспроизведения, разрешения и другие параметры были разбросаны по множеству баз данных.
Запросы работали медленно и непоследовательно.
Нужны были единое хранилище и сверхбыстрый доступ.
Новое хранилище метаданных Reddit должно было справляться с более чем 100 тысячами чтений в секунду при задержке меньше 50 миллисекунд, поддерживать последовательное создание и обновление данных, защищать от злонамеренных удалений и хранить все медиа в едином виде.
Самым большим узким местом были чтения.
Cassandra отлично масштабируется, но сложна для ad-hoc запросов и отладки и требует сильной денормализации.
Postgres реляционная, надёжная, легко отлаживается и позволяет делать гибкие запросы.
Reddit выбрал AWS Aurora Postgres.
Архитектура упрощённо включала Aurora Postgres для хранения, PgBouncer для connection pooling, API сервисный слой который экспонирует metadata API, клиентов включая приложения, фиды и рекомендательные системы.
Стандартная трёхуровневая архитектура была оптимизирована для высокой пропускной способности.
Стратегия миграции при нагрузке более 100 тысяч чтений в секунду включала Dual writes которые писали одновременно в новую и старую базу данных, Backfill который копировал исторические метаданные, Dual reads для проверки согласованности данных и постепенный перевод трафика.
Всё это происходило при непрерывной работе Reddit по всему миру.
Запись могла пройти в одной базе и провалиться в другой.
Решение включало Kafka CDC pipeline которая валидировала каждую запись, проверяла согласованность перед коммитом и логировала конфликты для ручного разрешения.
Старые данные из backfill могли перезаписать свежие записи.
Решение включало проверку конфликтов версий с помощью Kafka, логирование несоответствий отдельно и ручную проверку чтобы избежать потерь данных.
Производительность после миграции показала P50 latency меньше 2.6 миллисекунд, P90 latency меньше 4.7 миллисекунд и P99 latency меньше 17 миллисекунд.
Все это достигнуто без кэширования.😮
👉 @BackendPortal
Это безумный масштаб.
Но при миллиардах постов с изображениями GIF и видео Reddit столкнулся с серьёзной проблемой.
Эффективно хранить и отдавать метаданные медиа в масштабе.
С данными у Reddit не было проблем.
Проблема была в другом.
Метаданные медиа включая миниатюры, битрейты, URL для воспроизведения, разрешения и другие параметры были разбросаны по множеству баз данных.
Запросы работали медленно и непоследовательно.
Нужны были единое хранилище и сверхбыстрый доступ.
Новое хранилище метаданных Reddit должно было справляться с более чем 100 тысячами чтений в секунду при задержке меньше 50 миллисекунд, поддерживать последовательное создание и обновление данных, защищать от злонамеренных удалений и хранить все медиа в едином виде.
Самым большим узким местом были чтения.
Cassandra отлично масштабируется, но сложна для ad-hoc запросов и отладки и требует сильной денормализации.
Postgres реляционная, надёжная, легко отлаживается и позволяет делать гибкие запросы.
Reddit выбрал AWS Aurora Postgres.
Архитектура упрощённо включала Aurora Postgres для хранения, PgBouncer для connection pooling, API сервисный слой который экспонирует metadata API, клиентов включая приложения, фиды и рекомендательные системы.
Стандартная трёхуровневая архитектура была оптимизирована для высокой пропускной способности.
Стратегия миграции при нагрузке более 100 тысяч чтений в секунду включала Dual writes которые писали одновременно в новую и старую базу данных, Backfill который копировал исторические метаданные, Dual reads для проверки согласованности данных и постепенный перевод трафика.
Всё это происходило при непрерывной работе Reddit по всему миру.
Запись могла пройти в одной базе и провалиться в другой.
Решение включало Kafka CDC pipeline которая валидировала каждую запись, проверяла согласованность перед коммитом и логировала конфликты для ручного разрешения.
Старые данные из backfill могли перезаписать свежие записи.
Решение включало проверку конфликтов версий с помощью Kafka, логирование несоответствий отдельно и ручную проверку чтобы избежать потерь данных.
Производительность после миграции показала P50 latency меньше 2.6 миллисекунд, P90 latency меньше 4.7 миллисекунд и P99 latency меньше 17 миллисекунд.
Все это достигнуто без кэширования.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥2