Inside China’s Social Security System: Architecture, Security, and Performance Secrets

Interview Overview

Senior database engineer Eric (ID: eric0435) discusses the technical foundations of China’s social security information systems, covering architecture, middleware, security, high‑concurrency handling, disaster recovery, and performance optimization.

System Architecture

The majority of social‑security applications use a three‑layer J2EE architecture. Version 2 employs a client‑server‑server (C/S/S) model with an added application‑server layer to offload work from the Oracle database. Version 3 adopts a hybrid C/S/S & B/S/S design, separating the system into three distinct layers:

Application layer : defines functional modules and business logic.

Data layer : provides a unified, extensible industry data model.

Technical layer : supplies the underlying technology that supports the business.

Oracle is the standard database due to its high availability, scalability, security, and stability. WebLogic, an Oracle product, serves as the Java application server, offering standards compliance, unlimited scalability, rapid development, flexible deployment, and mission‑critical reliability.

Security and Concurrency Strategies

To protect a quasi‑financial system that interacts with hospitals, pharmacies, banks, and other government agencies, the following measures are applied:

Data exchange via generic XML over HTTP, allowing other systems to access data through web services instead of direct database connections.

A unified security layer with centralized authentication, authorization, and a single entry point; clients only communicate with the web server, keeping database details hidden.

Login controls, permission management, and operation‑audit logging to prevent malicious or accidental database modifications.

For high‑concurrency scenarios, the system uses connection‑pooling to dynamically manage database connections, separates business logic from data access, and employs clustering techniques to distribute load and improve throughput.

Disaster Recovery Practices

The platform relies on EMC RecoverPoint for same‑city, cross‑site disaster recovery. Regular DR drills (approximately monthly) are conducted to verify failover capability, because a DR system that is never tested becomes ineffective. An example is cited where a backup system using DG failed to synchronize two days of data, leading to service interruption during a primary‑site outage.

Performance Optimization Experience

Common causes of sluggish performance include poorly written SQL statements and suboptimal table designs. Specific incidents:

Adjusting the INITRANS parameter and moving tables resolved excessive enq: TX - allocate ITL entry wait events.

Redesigning aggregation tables (e.g., creating a pre‑summarized unit‑by‑insurance‑type table) eliminated costly group‑by and sort operations on multi‑billion‑row tables.

When diagnosing performance issues, the engineer first determines whether the slowdown is isolated to a single function or affects the entire system. For function‑level problems, the focus is on identifying and tuning the offending SQL. For system‑wide degradation, resource usage on both database and application servers is examined, and high‑resource processes are traced back to their sessions for analysis.

Future Outlook

With the rise of mobile internet, Beijing has launched a mobile social‑security app, enabling citizens to query contributions, balances, and policies on smartphones. Eric expects further innovation through new technologies that improve transparency and service quality for the public.