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

💰 Бизнес-требования и 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 поверх брокера ломает саму идею асинхронной архитектуры, превращая её в более сложный вариант привычного синхронного вызова.

Merge Baltic

Продолжу тему впечатлений о конференциях.
Конференция бренда Merge "сложилась" для меня лишь со второй попытки. Первый мой доклад отклонили, после чего стало ясно: углубленное изучение технических деталей здесь не всегда интересно. Поэтому я решила сменить тактику и предложила более философски ориентированную тему — и вот тогда мое выступление вошло в официальную программу мероприятия.

Самое яркое впечатление произвело место проведения: Светлогорск, уютный город в живописнейшей Калининградской области. Эта территория сама по себе похожа на природный музей-заповедник, наполненный чудесами природы. К тому же мне повезло попасть сюда именно осенью, когда золотые краски листвы сделали атмосферу особенно чарующей.

Теперь поговорим непосредственно о самом событии.

Моя любимая привычка закапываться в сложные темы тут не сработала. Вместо узких технических вопросов я переключилась на общие, понятные и интересные как техническим специалистам, так и представителям бизнеса. Именно в этом и есть главная фишка конференции: объединить представителей разных сфер вокруг общих проблем и обсудить возможные пути их решения.

Особенно запомнился Руслан Сафин. Его глубокомысленные размышления об архитектурных принципах программного дизайна были настолько вдохновляющими, что вполне могли стать отдельной самостоятельной лекцией.

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

Если охарактеризовать конфу одним словом — это дух «small talk»: непринужденные беседы и диалоги, формирующие живую интеллектуальную среду для всех участников.

Переходим к следующему мифу.

⚓️ Когда eventual consistency — это не про данные, а про бизнес-процессы

Моя "любимая" согласованность... в кавычках, потому что, мне кажется, я на своих докладах всем вынесла мозг с ней. Рассмотрим очередную ее грань...

Асинхронность часто связана с eventual consistency: данные рано или поздно синхронизируются. Это звучит безобидно — пока не проявляется в пользовательских сценариях...

Пример: заказ создан, но платёж «где-то едет»

Пусть пользователь оформляет заказ. Фронтенд получает успешный ответ: «Заказ создан». Через секунду он открывает историю заказов — а там заказа нет, потому что поток обработки платежей задержался, и сервис заказа пока не обновил статус.
Что думает пользователь?
«Сайт сломался, надо оформлять заново». Даже если бизнес-процесс формально корректен, пользователь все равно идет оформлять повторно.

Вот что стоит помнить:
🎲 Eventual consistency — это не только про репликацию данных.
Это про рассинхронизацию реальности и того, что видит пользователь!! Поэтому асинхронность вынуждает продумывать UX иначе.

🎲 Нужно объяснять пользователю, что происходит: «Платеж обрабатывается…». А это означает изменения интерфейса, API, состояния в БД, SLA на задержки.

🎲 Асинхронная архитектура = асинхронный бизнес.

🎲 Процессы меняются: появляется потребность в сагах, компенсационных транзакциях, промежуточных состояниях.


Иными словами, внедряя асинхронность, вы меняете не только технологию, но и то, как бизнес работает с реальностью.
Казалось бы, очевидное утверждение. Но оно не всегда вспоминается при проектировании. Поэтому призываю вас ❗️ сделать это утверждение своей парадигмой, когда вы проектируете асинхронные процессы.

Analyst Days
Финальная конференция сезона и знаковое событие в мире аналитики — AnalystDays. Давно мечтала посетить её лично, и вот, наконец, моя мечта сбылась именно в этот год!

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

Несмотря на масштаб, атмосфера остаётся дружелюбной и располагающей к нетворкингу. Можно легко найти собеседника по любой интересующей теме, включая идеи будущих докладов с программным комитетом.

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

Уже сейчас начинаю подготовку к новому сезону и активно собираю свежие мысли и идеи. Очень надеюсь на вашу помощь и поддержку: расскажите о направлениях, которые вам интересны.
Как вызнаете, я люблю практические кейсы и конкретные решения конкретных проблем, поэтому сухие мотивационные лекции вроде "как оставаться в ресурсе" меня ещё не зацепили. Если у вас есть интересные задачки, буду рада ознакомиться с вашими мыслями.