How to Design Scalable Business Systems: Database, Application, and SOA Strategies

1 Database Design Extensibility

When designing a business system, extensibility means the ability to flexibly respond to changing requirements while minimizing code smells caused by frequent changes.

1.1 Database Splitting

Database extensibility can be achieved through vertical and horizontal splitting. Vertical splitting separates tables into different databases based on business domains, while horizontal splitting distributes rows of the same table across multiple databases based on dimensions such as user or organization. The split should be transparent to the upper‑layer applications, which continue to access the database as if it were not split.

To hide the complexity of horizontal splitting, a Data‑as‑a‑Service (DaaS) middleware layer can be introduced. Examples of MySQL middleware include Cobar, Amoeba, Atlas, and Mycat. The architecture of Mycat is shown below:

Although middleware now supports distributed transaction processing, it still cannot fully support all SQL features, and challenges such as data routing and partitioning remain. Newer solutions like TiDB and PolarDB address these distributed database problems more effectively.

1.2 Database Design Extensibility

To accommodate uncertain field extensions, you can reserve flexible columns in tables or store additional data as a JSON string in a large text column. For highly variable schemas, a vertical table (entity‑attribute‑value) design offers maximum flexibility but complicates SQL queries.

Configuration tables (data dictionaries, global variables, code generation rules, etc.) can persist customizable business data, making it easier to modify without redeploying services.

When a single table grows to billions of rows (e.g., ESB service logs exceeding 500 million rows), partitioning by day improves query performance and simplifies backup and cleanup. Indexing (primary and secondary) is also essential for maintaining query speed.

Example of a partitioned table strategy:

//ISaveBefore.Process(Form Data);
//Save();
//ISaveAfter.Process(Form Data);

1.3 Application Layer Extensibility

Implement pre‑ and post‑save hooks (e.g., ISaveBefore.Process and ISaveAfter.Process) to allow custom logic before or after persisting data. This enables per‑customer customizations while keeping the core CRM codebase unchanged.

Business rules can be externalized into a rule library and selectively enabled via configuration tables, providing a lightweight alternative to full rule engines.

Using an AOP‑like approach to intercept and extend functionality offers a practical balance between flexibility and manageability.

2 Extensibility Design Based on SOA

SOA emphasizes assembling and orchestrating services at the upper layers, allowing changes in applications without modifying underlying services.

2.1 Data Layer

The data layer handles CRUD operations for shared master data and private component data, either by directly invoking DaaS services or domain‑specific data services.

2.2 Business Logic Layer

This layer composes technical, data, and business services to implement key functionalities, often using visual modeling tools (e.g., BPEL) or traditional code.

2.3 Presentation Layer

The presentation layer includes traditional web technologies (JSP, HTML, jQuery) and modern frameworks (Vue, React, Angular) that consume services from the logic layer.

3 Business System Extensibility Summary

Extensible design must consider database, application, business rule, and UI layers simultaneously. It should address both increased concurrency and evolving business requirements while minimizing recompilation and deployment. Over‑engineering extensibility can degrade performance, so a balanced approach is essential.