Пойдете в БД. А там например Master-Slave с лагом репликации)

Это вообще подход страшный

Вы храните сначала в приложении, а потом через какой то интервал в базу?

+

как много невероятно вероятных событий за один раз

Справедливо, но в случае с базой у вас рано или поздно данные будут консистентны. А вот то, что комментарий, который не записался в кеш, когда то туда попадет, вероятность меньше

А это как вы реализуете кеширование

В данном случае я про кейс, когда у вас несколько сущностей в одном месте

Этот вариант как мне кажется не самый разумный

Я все равно не вижу смысла кешировать вещи, которые не занимают у вас секунды

Либо сотни миллисекунд, если уж так

Но точно не тогда, когда вам пойти в базу 5мс, а в кеш 2

Обычно порядок сходить в бд это милисек, в локальный кеш микросек, в редис что-то среднее

и зачастую бессмысленное. Даже в банках  консистентность соблюдается только в платежных транзакциях. А в клиентских приложениях рассинхрон уже вполне норма. Отправил деньги, деньги ушли, а сумма на счету не обновилась. Ну или деньги пришли а в приложении показывается на счету еще старая сумма в течении нескольких минут. И ни кто не умирает

Ну вот так оно и будет

Здесь все неплохо, так даже делают, но вместо кэша используют нечто, что имеет некий лог записи (привет, redis). И записывают не асинхронно, а синхронно батчем) А еще используют не кеш, а выше мной упомянутую cassandra db, которые очень быстрые на запись и реплицируются

так вроде сначала пишут в бд, потом обновляют кэш. наоборот рискованно, кэш ведь потерять можно. опять таки обычный кейс - это масштабирование. Если у вас несколько экземпляров одного приложения и  у всех разная версия кэша получится. А зачем кэш? снизить нагрузку?
решать нагрузку надо сначала масштабированием и ресурсами, потому что это быстро и эффективно. наглухо закешироваться всегда можно успеть.

Нужна помощь с go модулями

У меня есть такой кейс. Юзеры могут делать записи по локации, которые живут 24 часа. Также они могут смотреть на карте популярные места исходя из количества постов. И масштаб просмотра не улица, или район, а вплоть до карты мира. То есть нужно показать, что в таком то участке столько такой уровень «оживлённости». Количество записей выводить не надо, оно используется только для определения, какой уровень показать на карте. Так что на консистентность счетчика можно подзабить.

То есть в базе мы храним запись с ее геохешем, чтобы можно было кластеризировать записи по локации.

Если таких записей сотни тысяч, то выборка (представляющая из себя агрегацию) по масштабу страны/мира уже выполняется секунды 3-4. Если записей миллионы, это вплоть до 20 секунд.

Такие вещи точно стоит кешировать. Можно было бы сделать джобу, которая ходила в базу, делала агрегацию и вываливала результат в другую таблицу, откуда мы могли читать. Но из-за огромного количества геокластеров, такая операция может занимать часы, потому что для каждого кластера надо агрегировать свои кластеры

Там фронт мобилы, че-нибудь да придумают локально, если хотят параллельно