Проблема обновления данных в толстом клиенте

В предыдущем посте я получил довольно интересные комментарии. Основная тема текущего поста - как обновлять информацию с Голоса в своей базе данных. Архитектура там будет своя, строиться будет на базовых принципах. @primus правильно отметил:

Зачем обновлять всех пользователей по крону? Может лучше парсить блокчейн Голоса по мере появления новых блоков и исходя из того, что в блоках записано - накатывать обновления в базе пользователей / статей / балансов / апвоутов и т.п. Тогда у вас не будет пустой работы о "обновлению" неактивных аккаунтов и будет только производительная деятельность по учёту реальных изменений.

В целом - идея здравая. И ее можно попытаться частично реализовать - начать рыть методом get_block и пробираться по блокчейну восстанавливая все данные в своей структуре. Возможно, я попытаюсь сделать что-то подобное. Это самый "правильный" способ, в теории. А вот на практике - не знаю. В одном блоке часто записано много операций. В них записано всё: и новые посты, и комментарии, и лайки, и переводы голоса, и создание аккаунтов. И изменение постов. И комментариев.

Более того - изменение постов и комментариев написаны в виде unidiff (читаем Универсальный формат Diff). Получается огромная линейка событий. И тут развилка в желаниях и возможностях. Получить конечный/актуальный контент можно по прямому запросу. А можно пройдя все исторические слепки воссоздать актуальный контент. Что же выбрать и почему?

По-правде говоря - толстому клиенту не зачем хранить всю историю изменений - это и так записано в Голосе, зачем дублировать эту информацию? Требуется последняя версия контента. И тут мы попадаем в следующую ловушку. Необходимость проходить рекурсивно все комментарии.

Рассмотрим пример - предыдущий пост и комментарии к нему. Как видно - API выдает лишь комментарии первой вложенности. Хотите загрузить дальше? Делайте еще один запрос. Рекурсия меня не пугает, но вот обработку данных она может запросто превратить в ад.

Для того, чтобы определиться - нужно в первую очередь разобраться, что проще и быстрее внедрить. Стоит ли держать у себя ВСЕ данные Голоса. Или стоит "собирать" их по-требованию от клиента. Зашел человек к пользователю, который давно не обновлялся, быстро подгрузилась/дополнилась история его постов и комментарии по API выборке с этого конкретного пользователя. Получится реализация кругами по воде. Запросили - дали + подгрузили связанные части.

Очень двоякая ситуация, не понятно как ее решить. Дорогу осилит идущий. Целостность контента тоже очень важна. Вопрос лишь в том, как получать новые данные через API. Думаю, если у меня удастся правильно отработать unidiff на контенте/комментариях в PHP, то стоит рассмотреть полный обход линейки блоков Голоса. А вы как считаете?