Багато проектів спочатку протягом перших кількох місяців не мають явної реакції, справжні проблеми зазвичай виявляються лише через 6-12 місяців.

Причина досить проста. Дані поведінки користувачів, записи стану, журнали — ці речі щодня додають лише кілька десятків КБ, але за рік їх сукупний обсяг становить 10-30 ГБ. Традиційне децентралізоване зберігання на цьому етапі починає виглядати пасивним — кожне оновлення вимагає переписування, історичні версії безперервно накопичуються, посилальні зв’язки стають все більш заплутаними.

Якщо поглянути з іншого боку? Варто розглядати "довгострокове накопичення" як початкову передумову. Об’єкт має зберігати свою ідентичність і посилання незмінними, але стан може постійно еволюціонувати, а не кожного року створювати новий об’єкт. В чому переваги такої конструкції?

З відкритих даних видно, що протоколи типу Walrus демонструють хороші результати у цьому напрямку: один об’єкт підтримує обсяг даних у МБ, один і той самий об’єкт може оновлювати стан кілька разів без зміни посилань, дані зберігаються з резервуванням між кількома вузлами, стабільність доступності перевищує 99%.

Реалістична оцінка: коли обсяг даних входить у фазу "часового зростання", цінність такої архітектури може бути важливішою за безперервне прагнення до низьких витрат. Але передумова — масштаб мережевих вузлів має розширюватися відповідно, інакше накопичені історичні дані стануть джерелом навантаження для системи.