缓存技术方案改造思考

这是我对一个正在进行的重构项目，缓存技术方案改造点之一的一个想法：
rc现有的实时缓存（其实也是准实时，失效时间的存在）设计：

存在的问题：现有的实时缓存方案（也并非真正意义上的实时，缓存失效时间的存在），与上游核心系统耦合度较高，核心系统强依赖下游欠核心系统，而且目前的查询服务性能也存在问题，比如区域销售豆腐块接口返回的数据量大，并且从tair->rc，rc->delivery需要经过两次网络传输，这之间网络传输及序列化、反序列化消耗大，而且出现问题时，由于排查链路和时间周期都长；

升级方案的的思考：解耦上游核心系统（如delivery）与资源中心的HSF服务，rc维护数据库数据与tair(ldb)集群数据的一致性(准实时)，外部系统的查询直连tair(ldb)，不走rc的HSF服务，实现rc系统的读写分离，初步设计如下：

这里之所以选择ldb是因为它tair持久化的存储引擎，使用ssd盘存储数据，保证了数据的安全不丢失，并且读写性能远远高于db；
借助TTD中间件指定一台机器运行定时任务，定时任务将db中上一次定时任务结束到这一定时任务开始前变化的数据，从数据库中筛选出来，根据这些数据匹配列表ldb对应中key,针对每一个value值变化的key都去db中捞出key对应的新value值，然后invalid 目前ldb中的value，然后将新value put到ldb中，这样就维护了，数据库与ldb数据的一致性；
rc的读client（如delivery）需要前置mdb缓存从ldb中拿到的数据（访问量巨大的话，如不做mdb缓存，ldb压力很大），查询的时候首先去查询mdb，若有数据，则直接返回，若没有再去查询ldb，在这个设计中，读client不需要调用任何rc的查询服务，rc应用只是负责db与ldb数据的一致性，实现了读client与rc的解耦，上游的如delivery这样核心系统不再需要依赖下游的欠核心的rc系统，交易链路精简；
这个设计存在的问题：还没法做到完全的实时（定时间隔的存在），选择一个较为合理的定时间隔，平衡系统解耦的好处与实时查询的牺牲，实现准实时的系统解耦，还是值得的；
各位看到此文章的大牛，请帮忙评估一下此改造方案的可行性及改造方案的优缺点，期待各位给出宝贵的建议，谢谢大家！