Designing a Scalable Insurance O2O Platform: Architecture, Services, and Data Strategies
This article explores how to build a high‑traffic insurance O2O platform for tens of millions of users by emphasizing simple micro‑service architecture, detailed functional requirements, performance targets, distributed storage, caching, service registration, and a practical technology stack for reliable, extensible backend development.
Why Simplicity Matters
Complex architectures hinder adoption; a simple micro‑service design wins because it is easier to evolve, especially for fast‑growing companies that need lightweight frameworks.
Scenario Overview
The target is an "Internet+" insurance platform serving 20 million online users, 20 000 sales agents, and handling up to 200 million orders per year, with performance goals such as 50 million daily page views and 2 000 TPS peak load.
Requirement Analysis
Core functional areas include B2C e‑commerce (product display, purchase, user account), agent management, case handling, customer management, insurance appraisal, legal aid, and various public services. Each function must meet quality attributes like timely response, security, robustness, scalability, and high concurrency.
System Analysis
Key performance requirements cover product expansion, B2C traffic, order processing concurrency, operational staff concurrency, and order volumes for short‑term, long‑term, and vehicle insurance.
Storage and Caching Architecture
Multiple databases are partitioned by domain with read/write separation and horizontal sharding where needed, using customer ID, agent ID, or other keys as routing identifiers. Distributed caching (Redis) and CDN/varnish are employed to alleviate database bottlenecks and provide fast data access at both presentation and logic layers.
Logical Architecture
The system follows a classic three‑tier model (presentation, control, service) with numerous domain‑specific services. Front‑end clients (web, mobile, agent apps) interact via an API gateway that aggregates data from underlying services, which are grouped into tool, core business, and domain services.
Service Architecture
Services register themselves in a Redis‑based service registry; clients discover service URIs via this registry. This lightweight approach replaces heavier solutions like Zookeeper/Dubbo and simplifies load balancing and health monitoring.
Distributed Transaction
To avoid the performance penalty of heavyweight distributed transactions, the design favors compensation via event‑driven mechanisms, custom transaction coordinators, or encapsulating transactional flows within a single service when necessary.
Development Architecture
The implementation stack includes Bootstrap, HTML, jQuery for the UI; Spring MVC 3.2, Spring Security 3.2, and RESTful services for the backend; MyBatis 3.2 for persistence; MySQL 5.6 as the database; Redis for distributed caching; Maven 3 for builds; and Tomcat 7 as the servlet container.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITFLY8 Architecture Home
ITFLY8 Architecture Home - focused on architecture knowledge sharing and exchange, covering project management and product design. Includes large-scale distributed website architecture (high performance, high availability, caching, message queues...), design patterns, architecture patterns, big data, project management (SCRUM, PMP, Prince2), product design, and more.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.