Конфигурация, реестр, кеш и хранилище

Эти четыре области часто встречаются рядом в эксплуатации, но решают разные задачи. @go-like/config объединяет источники в неизменяемые снимки и хранит последний корректный вариант. @go-like/registry публикует узлы и обнаруживает доступные endpoints. @go-like/cache хранит временные bytes-значения с необязательным TTL, а @go-like/store работает с долговечными записями через Context, revisions, TTL, CAS, prefixes и стабильную пагинацию.

Конфигурация читается из окружения, файлов, Consul, etcd или Vault KV v2 через @go-like/config-vault. Реестр поддерживает mDNS, Consul, etcd, Kubernetes EndpointSlice и ZooKeeper. Для кеша есть @go-like/cache-memory и @go-like/cache-redis. Store может использовать локальный snapshot с одним владельцем, Consul KV, etcd KV или Vault KV v2 через @go-like/store-vault. Каждый провайдер публикуется отдельно, поэтому лишний backend не попадает в зависимости.

Адрес, credentials и host capabilities передаются явно. Переносимые HTTP-провайдеры получают однопараметрический Fetch и не читают globals runtime. Токены отправляются только в headers и не попадают в публичные ошибки. После etcd compaction или Kubernetes 410 Gone watcher сначала получает свежий полный снимок. ZooKeeper watchers также перевзводятся после одноразового события или истечения сессии. Если отмена приходит после отправки multi, провайдер ждёт реальный результат и откатывает точное состояние; если результат остаётся неоднозначным, он закрывает сессию и восстанавливает ранее принятых владельцев регистрации.

File Store подходит для небольшого локального состояния, но не для нескольких процессов-писателей. Registry описывает временную доступность, а не долговечные бизнес-данные. Эти границы не дают API обещать гарантии, которых нет у backend.

Долговечность и поддержка TTL/CAS зависят от провайдера; store-memory теряет данные при выходе процесса.