Я пытаюсь понять, какая стратегия кэширования будет наилучшей в случае слоя REST API, который позволяет запрашивать и обновлять базу данных реестра клиентов. В настоящее время у нас есть 3 внешних сервера, все из которых общаются с центральным сервером базы данных.
Идея состоит в том, чтобы вернуть etag вызывающему клиенту с etag, совпадающим с идентификатором версии записи клиента (значение хеш-функции, которое обновляется при любом изменении в учетной записи) с вызовами обновления, принимаемыми только в том случае, если полученный etag соответствует идентификатору версии, хранящемуся на базу данных.
Предположим, что клиент выполняет GET для записи клиента, направляемой на сервер 1 балансировщиком нагрузки. Сервер 1 не имеет кэшированной записи о клиенте, поэтому будет запрашивать базу данных, локально кэшировать запись и возвращать запись в качестве ответа на вызов, включая заголовок etag.
Если приходит второй клиент и выполняет тот же GET для той же записи о клиенте, направляемой на сервер 2, сервер 2 также кэширует запись локально и возвращает тот же заголовок etag.
Предположим, что теперь первый клиент выполнил вызов обновления для той же записи через Сервер 1. Кэш Сервера 1 обновляется последними сведениями о записи, и первый клиент получает новый тег etag.
После этого второй клиент выполняет условный вызов get, предоставляя набор заголовков If-None-Match с полученным тегом etag. Запрос снова попадет на сервер 2. Я предполагаю, что сервер 2 по-прежнему кэширует старый etag и возвращает клиенту ответ 304 Not Modified. Это правильное предположение?
В этой ситуации клиент легко получит устаревшие данные, что повлияет на общую согласованность данных, видимых и используемых на стороне клиента.
Что необходимо для решения этой проблемы и обеспечения того, чтобы устаревшие данные о клиентах не возвращались клиентам в любое время?
Большое спасибо!
