Правильный вариант:
3️⃣ (Без кеширования), с оговоркой на вариант 2️⃣ для некоторых данных.

Объяснение
🟩 Почему вариант 3️⃣ — основной: Для строго консистентных данных, где критична абсолютная актуальность (например, текущий баланс), кеширование опасно. Пользователь может увидеть устаревшие данные и, например, совершить платеж, думая, что у него есть деньги. Любой TTL > 0 создает риск расхождения.

🟥 Почему не вариант 1️⃣ (Приложение): 30 секунд — это огромное окно неконсистентности для финансовых данных. Стратегия абсолютно неприемлема в контексте финансов.

🟧 Оговорка про вариант 2️⃣ (БД): Для истории операций, которая только добавляется, но не удаляется, можно использовать чтение с реплик (это форма кеширования). Пользователь может не заметить отставание в пару секунд, а нагрузка на основную базу снизится. Но для баланса это недопустимо.

Вывод: не все данные можно и нужно кешировать. Консистентность и актуальность иногда важнее производительности.

Хочу поделиться с вами статьей, тема которой сегодня волнует, я думаю, многих.

Что с ИТ-рынком?
Дефицит кадров? Перенасыщение? Что делать и куда бежать?
https://habr.com/ru/companies/ddosguard/articles/960606/

Статья холиварная (особенно в комментах).

От себя добавлю: в целом согласна с мнением редакции, но есть пара пунктов....

Работа для айтишника не может закончиться
Может. Для тех кто работает на создание ПО. Кто на поддержке, у того ситуация стабильнее.

В январе 2025 «Бизнес FM» стращал массовыми сокращениями в IT-отрасли (в реальности, если судить по приведенной Минцифры статистике, произошло прямо противоположное)
Противоположное? Серьёзно? На конференциях осеннего сезона я активно собираю статистику этого аспекта. И ещё никто не сказал мне "сокращения в моей компании? Не, не слышал..."

Мне интересно, что вы скажете. Что думаете о рынке? Что задело в статье? Что планируете делать дальше?
Делитесь!))

Ну очень приглянулось 😅
Весёлых вам праздников!

Немного о пагинации

Часто ли вы задумываетесь о пагинации при проектировании API? Честно говоря, я не задумывалась. Просто шла по накатанной (limitFrom, limitSize) и все. В кулуарах одной из конференций об этом зашел разговор, и я поняла, что у меня есть пробелы. А теперь делюсь с вами тем, что накопала по этому вопросу.
Оказалось, пагинация затрагивает архитектуру, производительность, UX и бизнес-логику.

Первый и главный вопрос: какую пагинацию использовать? Здесь есть два основных конкурента и один гибридный вариант.

🌖 На основе смещения (Классика)

📿 Как работает: limitFrom, limitSize (как я писала выше)

➕ Плюсы:
- Проста для понимания и реализации.
- Позволяет пользователю прыгать на произвольную страницу (например, с 1 на 10)

➖ Минусы:
- Низкая производительность на больших смещениях: Запрос в базу со смещением 10000 и размером 20 заставит БД пройтись по 10020 записям, прежде чем вернуть 20. Это считается "тяжелым" запросом.
- Если между запросами в набор данных добавились или удалились записи, страницы "поплывут". Пользователь может увидеть дубли или пропустить записи (если запись с предыдущей страницы сместилась вперед).

🔧 Когда использовать?
Для небольших, относительно статичных наборов данных, где важна возможность произвольного перехода по страницам, а производительность не критична.

🌖 На основе курсора

📿 Как работает: Вместо номера страницы используется указатель на конкретную запись. Обычно это уникальный, последовательно возрастающий столбец (например, id, created_at).

➕ Плюсы:
- Производителен, тк запрос использует индекс по курсорному полю и очень эффективен, даже для глубоких страниц.
- Устойчив к изменениям данных. Пользователь видит снимок данных на момент первого запроса (в рамках одной сессии).

➖ Минусы
- Нельзя прыгнуть на страницу 10, не пройдя предыдущие 9. Только "Вперед/Назад".
- Сложнее в реализации, потому что требует передачи курсора на клиент и правильной обработки на бэкенде.
– Курсор жестко привязан к конкретному порядку сортировки. Если нужно сортировать по разным полям, нужны разные курсоры.

🔧 Когда использовать?
Для больших, часто обновляемых наборов данных, где важны производительность и консистентность (ленты социальных сетей, бесконечный скролл, ленты транзакций).


🌖 Keyset
Разновидность курсорной. Более продвинутая форма, где курсором может быть составной ключ (например, (date, id)), что позволяет эффективно работать со сложными сортировками.

В следующий раз разберем критерии, по которым можно выбирать подход

Что учитывать при проектировании пагинации

💰 Бизнес-требования и UX
Ниже привела вопросы, которые можно задать бизнесу для принятия решения.

1. Прогнозируйте поведение пользователя. Нужен ли произвольный доступ к страницам? Или это "бесконечный скролл"?
2. Насколько критично, чтобы данные на 2-й странице были абсолютно актуальными? Можно ли допустить аномалии вроде дублей?
3. По каким полям возможна сортировка? От этого напрямую зависит выбор типа пагинации.
4. Требуется ли возможность выгружать большие объемы данных? Пагинация здесь может быть не лучшим решением, возможно, стоит предусмотреть асинхронную генерацию отчетов.

💽 На бекенде

1. Производительность БД:
- Всегда используйте индексы для полей, по которым делаете сортировку и которые используются в курсоре.
- Для пагинации по смещению оцените максимально возможное смещение.
2. Ответ API должен быть единообразным и содержать не только данные, но и мета-информацию.
3. Клиент не должен в явном виде знать данные для курсора. Это значит, у клиента не должно быть сырого id, он должен быть закодирован.
4. Если для получения данных нужны тяжелые джойны или агрегации (читай, сложная бизнес-логика), пагинация может стать очень дорогой. Рассмотрите кеширование, материализованные представления или денормализацию.

🎆 Фронтенд и Клиентская часть

1. Подумайте, какое представление вам подойдет: бесконечный скролл, классическая нумерация страниц, кнопка "Загрузить еще"?
2. Клиент должен корректно обрабатывать состояние "загрузки следующей страницы" и избегать дублирующих запросов.
3. При использовании пагинации с заменой URL (например, ?page=2), нужно обеспечить корректную работу кнопок "Назад/Вперед" в браузере.

🩼 Осторожно, грабли!
Завершаем цикл заметок по пагинации граблями, на которые можно наступить.

🔸 N+1 проблема при курсорной пагинации. Вы получили 20 id из основного запроса, но для каждой записи нужно подтянуть связанные данные (например, имя автора). Решение: жадная загрузка всех необходимых данных в одном ответе.

🔸 Неуникальный курсор. Если поле курсора (например, created_at) не уникально, записи могут "потеряться" на стыке страниц. В таких случаях используйте уникальный составной ключ, например, created_at и id.

🔸 Слишком большой page_size. Большой размер страницы может убить и БД, и сеть, и клиент. Вводите разумные ограничения и валидируйте входные параметры.

🔸 Отсутствие сортировки. Всегда явно указывайте order_by. Без этого порядок записей не гарантирован, и пагинация будет работать некорректно. Базы данных не обязаны возвращать данные в порядке первичного ключа по умолчанию.

🔸 Совместимость с фильтрацией и поиском. Пагинация должна корректно работать в сочетании с любыми фильтрами. Убедитесь, что индексы покрывают комбинацию полей для фильтрации и сортировки.

🔸 Подсчет количества записей Для Offset-пагинации запрос COUNT(*) на больших таблицах может быть очень медленным. Рассмотрите:
- Приблизительные подсчеты (например, из статистики БД).
- Отказ от подсчета общего числа страниц ("Показать еще" вместо "Страница 5 из 1000").
- Кеширование значения.

♎️ Чеклист для проектирования

📍 Определил поведение пользователя: произвольный доступ или последовательное чтение?
📍 Выбрал тип пагинации: смещение или курсор исходя из объема данных.
📍 Определил поля для сортировки и, если нужно курсора, убедился в их уникальности.
📍 Спроектировал контракт API: структура запроса (параметры) и ответа (метаданные).
📍 Учел производительность: проверил наличие нужных индексов, ввел ограничения на размер пакета.
📍 Учел комбинацию с фильтрами и поиском.
📍 Продумал обработку крайних случаев: пустой результат, последняя страница, невалидный курсор.
📍 Задокументировал принятые решения и ограничения для команды разработки.


У меня получилось вас убедить, что пагинация — это не просто "сделать запрос с LIMIT/OFFSET"?
Это комплексное архитектурное решение, которое напрямую влияет на отзывчивость приложения.

Кто идет на Analyst Days? Делитесь!

🚀Видео-анонс докладов Analyst Days 21!

Дарья Борисова "Практические аспекты реализации согласованности данных: паттерн Сага против Two-phase commit"
14.11 секция С 11:00
Также анонс можно посмотреть в ВК видео и YouTube😉

Analyst Days - территория новых идей!
14-15 ноября, Москва + онлайн-участие!❤️

Вас ждут:
✅ 2 дня, полных новых открытий и знаний
✅ 71 доклад, мастер-классов и круглых столов, где вы сможете получить ответы на все свои вопросы
✅ 600+ участников для обмена опытом
✅ 5 секций, чтобы углубиться в интересующие вас темы

⚡️программа
⚡️билеты
⚡️афиша
⚡️скидки
⚡️видео

#анонсad21

Осенний сезон конференций 2025 завершился! Формально это был мой второй сезон выступлений (первый состоялся этим летом на ЛАФ), однако по личным ощущениям полноценным сезоном стал именно этот период.

За два месяца я посетила четыре конференции, каждую из которых анонсировала заранее, но так и не успела подробно рассказать о результатах. Теперь же, когда эмоции утихли и остались лишь четкие выводы, готова представить небольшой анализ прошедших мероприятий. Я понимаю, что многие ждут сравнительного обзора, мол, какая конференция оказалась лучше или хуже. Однако каждая из них настолько уникальна, что прямое сравнение было бы неуместно. Вместо этого я хочу поделиться собственными впечатлениями и буду рада вашим ответным комментариям.

Стачка
Это первая конференция осеннего сезона. Она впечатляет масштабностью мероприятия буквально с первых минут: вечером накануне ты приходишь за бейджиком и оказываешься свидетелем монтажа большого числа стендов. Для меня это стало отличной возможностью выйти за пределы круга знакомых аналитиков и познакомиться с представителями разных специальностей, ведь в повседневной работе редко удается выбраться из аналитической среды. Эта встреча помогла мне накопить интересный материал для собственной статистики, касающейся вопросов IT-мира в целом. Так что, если вам любопытно узнать, какие вопросы я задаю представителям ИТ-отрасли вне зависимости от их должностей, отметьтесь реакцией 😁. Достигнем отметки хотя бы в 10 таких знаков — поговорим подробнее!

Что касается моего собственного выступления, стоит сказать, что я впервые была на "сборной солянке", когда разные специальности встречаются на одной площадке. Такая разнородность имеет плюсы и минусы одновременно. Плюс заключается в возможности послушать доклады абсолютно разных направлений, будь то архитектура или управление проектами. Минус — градус сложности тем снижается, поскольку востребованными становились темы, понятные широкой аудитории. В результате я осознала, что моя роль — скорее отраслевого эксперта, чьи доклады наиболее интересны коллегам-аналитикам или архитекторам, тогда как другим специалистам мои рассказы могут показаться менее релевантными. Одним словом, главная характеристика Стачки — универсальность.

Flow

Это была отраслевая конференция, менее масштабная, но покорившая меня своей особой атмосферой. Если у вас накопились вопросы по специальности, то здесь легко удается оперативно познакомиться с людьми, которым можно задать интересующие вас вопросы. Мне особенно запомнился скрупулёзный подход организаторов ко всем деталям мероприятия: начиная от зон для обсуждений возле залов и заканчивая наличием гримёра прямо на площадке. Важнейший критерий оценки любой конференции — уровень выступлений, и тут он оказался безупречным. Общаясь с организатором, человеком глубоко погружённым в сферу ИТ, поняла, почему мероприятие получилось таким уютным и комфортным для участников: оно создано именно айтишниками для айтишников, где не соскучишься ни на официальных секциях, ни на развлекательной программе.
Главное слово, характеризующее для меня эту конференцию, — «уют».

Не могла не прислать. Что думаете: "совсем поехавшие" или "жиза"?

Хочу поговорить с вами об асинхронности. Разговор предстоит длинный, и прежде чем мы начнем, предлагаю четко разграничить 2 понятия: очередь и брокер.
Возможно, для большинства присутствующих мое предложение покажется странным, потому что всё и так понятно, зачем говорить очевидное...
Но многократно на собеседованиях кандидаты встают в тупик, когда я спрашиваю: очередь и брокер - это одно и то же? Цель такого вопроса не завалить человека, а понять, любит ли он свою профессию, чтобы вникать в вопросы чуть глубже, чем иногда требуется. Как относитесь к такой позиции? Расскажите в комментариях, по какому нестандартному принципу вы отличаете подходящего кандидата?

⛓️‍💥 Очередь

Очереди используются для хранения сообщений в порядке поступления и обработки их последовательно: первый пришел - первый вышел.

Особенности
- Сообщения обрабатываются одним потребителем.
- Очередь обеспечивает строгий порядок доставки сообщений.
- Подходит для ситуаций, когда важна последовательность обработки данных.

⛓️ Брокер сообщений

Брокеры сообщений обеспечивают передачу сообщений между различными приложениями или компонентами системы. Иными словами - транспорт и маршрутизатор.

Особенности
- Поддерживает модели "publish-subscribe" (pub/sub), позволяя множеству потребителей получать одно сообщение одновременно.
- Является частью асинхронного мира
- Работает на протоколах передачи сообщений (AMQP, MQTT и тд)

Недавно нашла вот такой полезный доклад о стоп-словах аналитика. Показался очень полезным, поэтому показываю вам

кто интересуется архитектурой ИИ, тому полезно будет узнать о митапе Сбера
16 декабря с 11.00

Приступим к асинхронности. Она, конечно же, скрывает много подводных камней, которые мы и начнем поднимать со дна :)
Асинхронные системы давно стали модным архитектурным выбором. «Поставим Rabbit/Kafka — и всё взлетит» звучит примерно как «перепишем на микросервисы — и станет быстрее» 😆😆😆.
На практике же асинхронность — это не инструмент, а архитектурное мировоззрение, которое меняет буквально всё: от того, как устроена модель данных, до того, как работает команда разработки и как взаимодействуют с системой пользователи.

Недавно поймала себя на мысли, что мне очень нравится делать разборы в формате развенчивания мифов (часть из которых и были моим мнением, пока я не стала копать). Ниже — разбор основных иллюзий, с которыми сталкиваются команды, делая первые шаги в сторону асинхронности.

🪝 Скрытая синхронность: RPC поверх брокера и его ловушки

Первая ошибка, в которую попадают команды: пытаясь уйти от синхронного REST, они переносят те же паттерны поверх брокера сообщений. Возникают решения вида RPC over MQ, где:
— сервис A кладёт сообщение в очередь
— сервис B обрабатывает его и отправляет ответ в «reply queue»
— сервис A продолжает выполнение после получения ответа
На бумаге — асинхронность. На практике — тот же синхронный вызов, только скрытый в очередях и callback’ах.
Чем это опасно?

1. А смысл?
Команда думает: «Мы же используем брокер, всё асинхронно». На деле — они не избавились от синхронности, а просто спрятали её глубже, добавив ещё больше точек отказа.

2. Хрупкость цепочки
Теперь между клиентом и исполнителем не один сетевой хоп, а два, три или четыре: публикация, маршрутизация, обработка, обратная публикация. Любой сбой превращает ответ в «висит, но непонятно где».

3. Возврат к блокирующей модели
Треды всё равно ждут ответа. В результате система одновременно не получает преимуществ асинхронности и тащит всю связанную сложность.

🗼Итог: RPC поверх брокера ломает саму идею асинхронной архитектуры, превращая её в более сложный вариант привычного синхронного вызова.