进入第4个运行年度，业务数据量沉积给产品带来了性能问题。为提高软件的可用性。对工作流组件进行了全面构建。构建过程分为几步进行：缓存优化/消息组件独立/运行数据分区【运行库/业务库/业务沉积库】。
缓存优化：在为规划独立缓存服务前，对变更频率较低数据基础数据进行了较长时间的内存缓存[30分钟]；对更新较为频繁的数据采用来了短频缓存机制[只满足request请求级别]。改善后，数据库的直接访问次数大大降低。
消息组件独立：工作流引擎核心表不再为消息显示提供数据源，引入独立的工作流消息套表，使工作流核心表为消息组件提供一次性构建数据源。构建后消息将独立提供读服务。消息不再直接依赖核心表，工作流监测服务对消息的延后重构提供了可行方案，使工作流引擎进入可自我修复阶段。
运行数据分区：在数据量小的时候，工作流所有数据都在核心表中，简单了工作流构建方案。随着时间的数据沉积与业务全面推广，并发量与数据量的双层压力，使工作流引擎无法有效提供及时服务。经过对数据统计，在几个大集团的数据量中，总数据量在100w。运行中的业务量在5w,及审批记录量在20w左右，按照这个数据积累进程，年度沉积量将进入50w。为在不增加硬件前提下提供平稳的响应体检，对数据进行读写分离改造，及为执行中数据提供运行库【5w-30w】数据量，业务库【存储近N年的完成业务】，业务沉积库【存储N年前的完成数据】。
flowable采用了类似的方法，但本次改造在它的基础上进一步引入业务沉积库概念。将提供更为长时间的高可用性方案。