Designing a Scalable Insurance O2O Platform: Architecture, Services, and Storage

Requirement Analysis

Based on insurance business documents, a core requirement matrix was derived, covering major functional areas such as B2C e‑commerce (product display, purchase, user center), agent management, policy queries, case management, customer management, and various auxiliary services. Each function emphasizes timeliness, security, robustness, and usability, with constraints related to multiple insurance types.

System Analysis

Key performance targets include 50 million daily page views, peak concurrency of 2 000 TPS for B2C purchases, and handling up to 2 billion annual orders across short‑term, long‑term, and vehicle insurance. High concurrency and extensibility are prioritized, with scalability and security ranked as the most critical quality attributes.

Storage and Caching Architecture

Multiple databases are designed with read/write separation and horizontal sharding where appropriate. Routing keys such as customer ID, agent ID, or order ID are used for sharded databases. A distributed cache (Redis) complements the storage layer, providing fast access for hot data and reducing database load.

Logical Architecture

The system follows a classic three‑tier model: presentation layer (web, mobile, admin), service layer (business services), and data layer (databases, caches). An API gateway mediates between heterogeneous clients and backend services, enabling composition of multiple service calls per UI request.

Service Architecture

Services register themselves in a Redis‑based service registry; clients discover service URIs via this registry. The design favors a lightweight registration mechanism over heavyweight solutions like Zookeeper, simplifying deployment while supporting load balancing through Nginx.

Distributed Transaction Strategy

Distributed transactions are avoided when possible. When required, three approaches are suggested: encapsulating transactional operations in a dedicated service using XA or chain‑style coordination, employing event‑driven compensation via persistent message queues, and implementing a custom transaction manager that tracks workflow state and performs compensating actions on failure.

Development Stack

Front‑end: Bootstrap, HTML, jQuery. MVC framework: Spring MVC 3.2. Security: Spring Security 3.2. REST API: Spring MVC Rest. Persistence: MyBatis 3.2 with MySQL 5.6. Distributed cache: Redis. Build tool: Maven 3. IDE: MyEclipse 10. Version control: SVN 1.8.22. Application server: Tomcat 7. JDK: 1.7 (Java EE 5).

Key Diagrams