4727. Интернет-магазин: страницы товаров тормозят из-за высокой нагрузки на БД. Как снизить нагрузку?
Anonymous Quiz
11%
Добавить индексы на все поля
82%
Внедрить кэширование (Redis)
3%
Увеличить мощность сервера
4%
Перейти на NoSQL
Redis или Memcached хранят часто запрашиваемые данные в оперативной памяти, обеспечивая ответ за миллисекунды.
Для страниц товаров можно кэшировать по ключу product:{id} с TTL (например, 5 минут) или инвалидировать кэш при изменении цены/наличия.
Это снижает число запросов к основной БД на 90–95%.
❌ Индексы (A) уже должны быть на полях, используемых в WHERE (например, product_id). Добавление индексов на все поля бесполезно и даже вредно (замедляет запись).
❌ Увеличение мощности сервера (C) — временное решение, не решающее проблему масштабирования. При росте нагрузки снова упрётесь в потолок.
❌ Переход на NoSQL (D) — сложный и дорогой шаг, не гарантирующий успеха. Часто проблемы решаются кэшированием и оптимизацией запросов, без смены СУБД.
Вывод: Кэширование — первая линия обороны при проблемах с производительностью чтения. Аналитик должен закладывать требования к кэшированию и стратегии инвалидации.
Please open Telegram to view this post
VIEW IN TELEGRAM
4728. Система управления задачами: нагрузка на чтение в 10 раз выше, чем на запись. Как разделить модели чтения и записи?
Anonymous Quiz
40%
CQRS
14%
CRUD с одной БД
34%
Master-slave репликация
12%
Шардирование по user_id
Оптимизировать модель записи под целостность (нормализованная форма).
Создать отдельные модели чтения (денормализованные, с предвычисленными данными) для быстрых запросов.
Каждую модель масштабировать независимо (например, чтение может обслуживаться репликами).
❌ CRUD с одной БД (B) — классический подход, но при сильном дисбалансе нагрузки он приведёт к тому, что чтения будут «забивать» ресурсы, мешая записи.
❌ Master-slave репликация (C) помогает распределить нагрузку чтения на реплики, но модели данных остаются одинаковыми (нормализованными). Для сложных отчётов или представлений это может быть неэффективно.
❌ Шардирование (D) решает проблему объёма данных, но не разнородности нагрузки. Оно не оптимизирует модель под специфику чтения.
Вывод: При сильном дисбалансе нагрузок чтения и записи, а также при сложных представлениях данных, CQRS — архитектурный паттерн, позволяющий достичь высокой производительности и масштабируемости.
Please open Telegram to view this post
VIEW IN TELEGRAM
4729. В системе бронирования отелей два менеджера одновременно пытаются забронировать последний номер. Как гарантировать, что номер не продадут дважды?
Anonymous Quiz
16%
Оптимистическая блокировка (проверка версии)
60%
Пессимистическая блокировка (блокировка строки в БД)
8%
Уникальный индекс на номер отеля
15%
Обрабатывать ошибки дубликатов и уведомлять второго
✅ Пессимистическая блокировка — самый надёжный способ. В начале транзакции вы выполняете SELECT ... FOR UPDATE. Эта команда блокирует строку в базе данных до завершения транзакции. Второй менеджер, попытавшись прочитать ту же строку с FOR UPDATE, будет ждать. Когда блокировка снимется, он увидит, что номер уже занят. Это гарантирует, что одновременных бронирований не произойдёт.
❌ Оптимистическая блокировка (A) работает иначе: вы читаете данные без блокировки, запоминаете версию, а при записи проверяете, не изменилась ли версия. В нашем случае оба менеджера прочитают номер как свободный, оба попытаются записать, и один получит ошибку. Это допустимо, но пользователь узнает об отказе только после попытки, что хуже для UX.
❌ Уникальный индекс (C) на поле (hotel_id, room_number) предотвратит вставку дубликата на уровне БД. Но проблема та же: оба менеджера могут попытаться вставить, одна вставка упадёт с ошибкой, второй успеет. Это лучше, чем двойная продажа, но второй менеджер получит неожиданную ошибку.
❌ Обрабатывать ошибки (D) — значит полагаться на то, что приложение само разберётся с конфликтом. Это ненадёжно и усложняет код.
Вывод: Для критически важных ресурсов (билеты, номера, товары) используйте пессимистическую блокировку. Она гарантирует целостность и даёт пользователю мгновенную обратную связь.
Please open Telegram to view this post
VIEW IN TELEGRAM
4730. Мобильное приложение использует API. Разработчики хотят изменить формат ответа, добавив новые поля. Как сделать это без поломки старых версий приложения?
Anonymous Quiz
3%
Оповестить пользователей и попросить обновить приложение
87%
Версионировать API (v1, v2) и поддерживать обе версии параллельно
1%
Менять формат, старые приложения пусть падают
9%
Добавлять поля в конец ответа, старые приложения их проигнорируют
✅ Версионирование API — отраслевой стандарт. Вы начинаете с /api/v1/.... Когда нужно внести изменения, несовместимые со старой версией, вы создаёте /api/v2/.... Старые приложения продолжают работать с v1, новые используют v2. Через некоторое время, когда доля старых клиентов станет ничтожной, вы можете отключить v1. Это гарантирует, что ни одно приложение не сломается.
❌ Оповестить пользователей (A) — не работает. Пользователи не обновляют приложения мгновенно, некоторые могут вообще не обновить. Вы не можете полагаться на их действия.
❌ Пусть падают (C) — недопустимо для серьёзного продукта. Это потеря пользователей и репутации.
❌ Добавлять поля в конец (D) — работает только для добавления необязательных полей, но не для изменений структуры. Если нужно переименовать поле или изменить тип данных, старые приложения сломаются.
Вывод: Версионирование API должно быть заложено в архитектуру с самого первого дня. Это единственный способ эволюционировать систему, не ломая клиентов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Кажется, знакомая история, не правда ли? Бесконечный поиск "волшебной таблетки" в мире онлайн-маркетинга может вымотать кого угодно. Обещания золотых гор, гуру, предлагающие секретные формулы успеха, и горы потраченных впустую денег.
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/wW0ESLUtsM0wZTQy
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/wW0ESLUtsM0wZTQy
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/wW0ESLUtsM0wZTQy
Результат:
😃за 3 дня работы, +60 подписчиков и 3 продажи сразу.
Добавляй себе всю папку https://t.me/addlist/wW0ESLUtsM0wZTQy и
Записывайся в подборку🫶
Чувствуете себя белкой в колесе, которая крутится, но не двигается с места?
🔥ПРИВЛЕКАЙ ПОДПИСЧИКОВ И ПОЛУЧАЙ ЕЖЕДНЕВНЫЕ ЗАЯВКИ БЕСПЛАТНО, С ПОМОЩЬЮ ЭТОГО МЕТОДАРезультат:
😃за 3 дня работы, +60 подписчиков и 3 продажи сразу.
Добавляй себе всю папку https://t.me/addlist/wW0ESLUtsM0wZTQy и
Записывайся в подборку
Please open Telegram to view this post
VIEW IN TELEGRAM
4731. Мобильное приложение использует API. Разработчики хотят изменить формат ответа, добавив новые поля. Как сделать это без поломки старых версий приложения?
Anonymous Quiz
2%
Оповестить пользователей и попросить обновить приложение
91%
Версионировать API (v1, v2) и поддерживать обе версии параллельно
1%
Менять формат, старые приложения пусть падают
6%
Добавлять поля в конец ответа, старые приложения их проигнорируют
✅ Версионирование API — отраслевой стандарт. Вы начинаете с /api/v1/.... Когда нужно внести изменения, несовместимые со старой версией, вы создаёте /api/v2/.... Старые приложения продолжают работать с v1, новые используют v2. Через некоторое время, когда доля старых клиентов станет ничтожной, вы можете отключить v1. Это гарантирует, что ни одно приложение не сломается.
❌ Оповестить пользователей (A) — не работает. Пользователи не обновляют приложения мгновенно, некоторые могут вообще не обновить. Вы не можете полагаться на их действия.
❌ Пусть падают (C) — недопустимо для серьёзного продукта. Это потеря пользователей и репутации.
❌ Добавлять поля в конец (D) — работает только для добавления необязательных полей, но не для изменений структуры. Если нужно переименовать поле или изменить тип данных, старые приложения сломаются.
Вывод: Версионирование API должно быть заложено в архитектуру с самого первого дня. Это единственный способ эволюционировать систему, не ломая клиентов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4732. На диаграмме классов отношение, показывающее, что один класс является частным случаем другого
Anonymous Quiz
12%
Ассоциация
12%
Агрегация
66%
Наследование
10%
Зависимость
Please open Telegram to view this post
VIEW IN TELEGRAM
4733. Вы разрабатываете систему обработки заказов для интернет-магазина.
Какой подход к использованию брокера сообщений лучше всего соответствует этим требованиям?
Какой подход к использованию брокера сообщений лучше всего соответствует этим требованиям?
Anonymous Quiz
52%
RabbitMQ с персистентными очередями, подтверждениями от потребителя и постановкой при сбое.
28%
Kafka с одним partition на каждого пользователя.
10%
Amazon SQS с FIFO очередью и Dead Letter Queue для необработанных сообщений.
10%
Активная очередь на базе PostgreSQL (таблица с SELECT ... FOR UPDATE SKIP LOCKED).
🤔4
acks=all гарантирует, что сообщение считается записанным только после подтверждения от всех реплик – потеря данных исключена.
enable.idempotence=true предотвращает дублирование сообщений при повторных попытках продюсера (даёт exactly-once семантику на стороне записи).
Партиционирование по ключу (например, userId) гарантирует строгий порядок сообщений в рамках одной партиции.
Consumer с isolation.level=read_committed читает только зафиксированные транзакции, избегая чтения незавершённых записей.
❌ Почему не другие варианты:
A (RabbitMQ): Обеспечивает at-least-once, но не exactly-once без сложных доработок на стороне потребителя (дедупликация). Порядок сохраняется только в рамках одной очереди при одном потребителе, но при масштабировании порядок может нарушиться.
C (SQS FIFO): Технически тоже подходит (гарантирует exactly-once и порядок), но имеет ограничения по пропускной способности (3000 сообщений в секунду) и менее гибок для сложной потоковой обработки.
D (БД как очередь): Не является брокером сообщений, создаёт высокую нагрузку на БД, сложно масштабируется и не даёт встроенных гарантий exactly-once без дополнительной логики.
Вывод: Для систем с требованиями порядка, exactly-once и отказоустойчивости Kafka — индустриальный стандарт.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1