У меня есть такой кейс. Юзеры могут делать записи по локации, которые живут 24 часа. Также они могут смотреть на карте популярные места исходя из количества постов. И масштаб просмотра не улица, или район, а вплоть до карты мира. То есть нужно показать, что в таком то участке столько такой уровень «оживлённости». Количество записей выводить не надо, оно используется только для определения, какой уровень показать на карте. Так что на консистентность счетчика можно подзабить.
То есть в базе мы храним запись с ее геохешем, чтобы можно было кластеризировать записи по локации.
Если таких записей сотни тысяч, то выборка (представляющая из себя агрегацию) по масштабу страны/мира уже выполняется секунды 3-4. Если записей миллионы, это вплоть до 20 секунд.
Такие вещи точно стоит кешировать. Можно было бы сделать джобу, которая ходила в базу, делала агрегацию и вываливала результат в другую таблицу, откуда мы могли читать. Но из-за огромного количества геокластеров, такая операция может занимать часы, потому что для каждого кластера надо агрегировать свои кластеры
Я тут пока писал придумал схему получше: для топ уровня просмотра кешировать джобой (потому что юзеру, хоть и одному-двум, ждать 20 секунд ну не очень), на среднем уровне кешировать по запросу, а на детальных уровнях может не кешировать вовсе, чтобы карта там была максимально актуальна