High availability across Alibaba Cloud and Tencent Cloud: lessons from manufacturing and finance projects
How to balance dual-cloud deployment, elastic scaling, disaster recovery and cost under peak traffic and demanding reliability requirements.

1. Identify when two clouds are justified
Dual-cloud deployment should not be the default. It offers a clear benefit when business-continuity requirements are high, single-cloud risk is unacceptable and the team can operate across providers.
Manufacturing and financial systems often have stricter availability and audit requirements. These settings are better suited to combining active-active operation within a region with disaster recovery in another region.
2. Define service and data boundaries
Separate core transactions, supporting services, and analytics and reporting. Prioritize consistency and recoverability for transactions, and scalability and cost control for reporting.
Set recovery point and recovery time objectives (RPO and RTO) for the data layer. Excessive synchronization raises costs, while insufficient synchronization can make failover unusable.
3. Validate the architecture through failure exercises
An architecture diagram can look complete without demonstrating that the system works during a failure. Run exercises at least quarterly, covering network isolation, database failures, dependency timeouts and configuration rollback.
Monitoring should support detection, diagnosis, response and review. Align metrics and alert severity with the on-call process.
4. Engineering governance: make delivery sustainable
Most technical solutions can be made to work for an initial release. The real difference is whether a team can keep improving them reliably over the next six to twelve months. Make architecture reviews, API reviews, staged rollouts and rollback plans part of the normal process rather than last-minute additions. Standardized development practices help maintain delivery quality as new people join.
Align the size of requirements with the size of releases. Slow iteration often comes from oversized work packages that lengthen testing and integration, rather than slow coding. Release small increments that can be accepted independently to reduce risk and help the business validate value sooner.
- Establish a shared technical baseline for coding standards, branching, API contracts and error codes.
- Have a staged rollout plan and a one-step rollback path ready before release.
- Maintain on-call runbooks and incident-response procedures for critical paths.
5. Performance and reliability: set targets during design
Discovering performance problems only during load testing can greatly increase architecture costs. Define a capacity model during design: peak concurrency, request patterns, frequently accessed data and acceptable external-dependency latency. Use it to plan caching, asynchronous queues, rate limits and degraded modes.
Reliability also needs separate layers of responsibility. Entry points need traffic controls, business logic needs state consistency, dependencies need timeouts and circuit breakers, and data needs recovery objectives (RPO and RTO). Layered metrics make root causes easier to locate than a single availability figure and help teams improve continuously.
- Define service-level objectives for critical paths before selecting the implementation.
- Keep load-test reports and exercise records for peak-traffic scenarios.
- Organize dashboards by entry points, business logic, dependencies and data.
6. Connect technical work to measurable business results
A project may feel successful after launch without making its value easy to demonstrate. Agree at kickoff to track both business and technical measures, such as conversion, response time, incident-recovery time and operational productivity. Reviews can then assess effectiveness using evidence rather than impressions.
Hold a monthly review of outstanding problems, metric changes and next steps to keep engineering and business priorities aligned. A continuous, measurable feedback cycle is a core long-term strength of an effective technical team.
- Connect each iteration to one or two verifiable measures.
- Record benefits alongside trade-offs in performance, cost and staffing.
- Use the evidence to guide architecture changes and resource allocation.
Practical Guidance
Starting from High availability across Alibaba Cloud and Tencent Cloud: lessons from manufacturing and finance projects, align business goals with current capabilities and pick the highest-confidence improvement to validate first.
If your work intersects with Dual-cloud architecture, High availability, run a small pilot to validate the workflow and data loop before scaling.
- Define clear success metrics and expected lift
- Reuse existing components and data assets
- Start where user impact is the highest
Delivery Rhythm
Ship tangible outcomes in 2-4 week iterations, then solidify stability and reusability as the next milestone.
Keep product, design, engineering, and data in lockstep to ensure requirements, experience, and implementation stay aligned.
Key Takeaways
- Define business-continuity goals before choosing dual-cloud deployment.
- Set data boundaries before synchronization policies.
- High availability needs to be demonstrated through failure exercises.
Related Articles
How AI interior design comes together: from Blender to real-time exploration
Thomas Ricouard’s house project connects requirements, floor plans, Blender/Python, Cycles renders and UE5 through repeated checks and revisions.
Read MoreOnce AI builds a scene, how do you turn it into a playable game?
Emm Tee’s PaperRoute shows the work beyond a generated scene: establish a gameplay loop, then review art, characters and movement separately.
Read MoreA small-group lesson with PikaTo: classroom points, homework checks and feedback
A sample lesson workflow for preparing rules, recording participation, checking homework and reviewing feedback before sharing it with parents.
Read More