We've noticed a technical article circulating on Juejin (掘金): an engineer used Spring's FactoryBean (Spring's "object factory" interface) together with JDK dynamic proxies to weld Redis active-active—two datacenters reading and writing simultaneously, backing each other up—directly into Spring business code. Zero middleware, zero business refactoring. What's worth noting is that the root cause of frequent AI product outages often isn't the model, but this "nobody wants to write" infrastructure layer.
What This Is
Redis active-active solves the problem of "datacenter A goes down, datacenter B still serves normally." The traditional approach is to layer a synchronization middleware outside Redis (Redis-Shake, CloudCanal, RedisSyncer) so the two datacenters replicate data to each other. This author argues that path has problems: the dual-write logic hides outside the application, and when things break, you have to dig through sync logs, lengthening the troubleshooting chain.
His solution sinks the dual-write into the application layer. He uses Spring's FactoryBean interface to wrap a JDK dynamic proxy shell around the Redis client before delivery: externally it's an ordinary RedisDualClient interface, drop-in injection for business code; internally it automatically replicates one write to both datacenters and routes one read to the nearest one.
Judgment: this isn't disruption, it's a tradeoff. Middleware solutions are general-purpose but black-box; application-layer solutions are controllable but push complexity onto the business team.
Industry View
Supporters argue this is the right direction—disaster recovery should bind to application semantics in the first place. What middleware does is "invisible work," and the hardest thing to locate is exactly this kind of failure. Details like "no matter how good the shell, if the type doesn't match, Spring won't let it through the door" are judgments only someone who's actually stepped in the hole would write.
Opposition deserves a hearing too. FactoryBean is a relatively niche API in Spring; if nobody on the team is familiar with it, the onboarding cost for newcomers spikes. The core hard problems of active-active—split-brain (both datacenters think they're master) and data conflicts—this solution doesn't truly solve; it just moves the troubleshooting point closer. The price of "zero business code changes" is that ops, configuration, and monitoring complexity gets pushed to the business team—not necessarily a good deal for small-to-mid companies.
Impact on Regular People
For enterprise IT: When traditional industries launch AI products, model selection is the visible investment; underlying reliability (Redis active-active, datacenter disaster recovery) is the invisible one—but what users actually perceive is usually the latter.
For careers: The hotter AI gets, the more valuable engineers who write this "boring infrastructure" become. Model-tuning roles will saturate; the person who can locate a dual-write conflict in alerts at 2 AM will always be scarce.
For the consumer market: AI products "looking smarter" is model-layer progress; "your 2 AM order not losing the shopping cart" is infrastructure-layer progress. These two advances aren't linked—consumers shouldn't conflate them.