我们有一个系统(Java web应用程序)已经积极开发/维护了很长时间(大约十年)。
我们正在做的是实现一个RESTful API到web应用程序。这个web应用程序，使用Jersey，将是一个单独的项目，目的是它应该能够与主应用程序一起运行或部署在云中。
由于我们的应用程序的性质和年龄，我们不得不在数据库(postgres)上实现一个(有点)全面的缓存层来帮助降低负载。无论如何，对于RESTful API，其思想是GET请求将首先转到缓存而不是数据库，以保持数据库的负载。
缓存将以一种方式填充，以帮助确保大多数注册API用户需要的东西应该在那里。
如果存在缓存缺失，则应从数据库中检索所需的数据(也在进程中输入到缓存中)。
显然，这对于我代码中的RESTful端点方法应该是透明的。我们提出了创建"Broker"来处理与DB和缓存之间的通信的想法。REST层将简单地传递id(如果寻找检索)或填充的Java对象(如果寻找插入/更新)，代理将负责检索/更新/无效等。
还有可扩展性的问题。首先，API将与其他服务器一起存在，因此访问数据库不会成为问题，但是如果我们部署到云，我们将需要一个不同的Broker实现，该实现将以不同的方式(可能通过使用内部API)与系统(即数据库)通信。
我已经有一个关于如何实现这一点的粗略想法，但它打击了我，这可能是一个合适的模式可能存在的问题。如果我能遵循既定的模式，而不是想出自己的解决方案，那可能是一个更好的选择。什么好主意吗?
Ehcache有这样一个缓存的实现，它调用SelfPopulatingCache。
请求被发送到缓存，而不是数据库。然后，如果有一个缓存丢失Ehcache将调用数据库(或任何外部数据源你有)代表你。
你只需要实现一个只有一个方法的CacheEntryFactory:
Object createEntry(Object key) throws Exception;
没有模式。只需将初始DB服务隐藏在接口后面，围绕其预期行为构建测试，然后切换到使用缓存层的实现。我想依赖注入将是帮助您做到这一点的最好方法。
听起来像装饰器模式将满足您的需求:http://en.wikipedia.org/wiki/Decorator_pattern.
您可以创建用于数据访问的DAO接口，如:
Value get(long id);
首先创建一个直接的DB实现，然后创建一个调用底层DAO实例的缓存实现，在这种情况下应该是DB实现。
缓存实现将尝试从自己的托管缓存中获取值，如果失败则从底层DAO获取值。
因此，您的旧应用程序或REST将只看到DAO接口，而不知道任何实现细节，并且在将来您可以自由地更改实现。
透明缓存HTTP请求的最佳设计模式是使用HTTP缓存