What Core Design Principles Drive Reliable Financial Software?

“No matter how great my successes, the main reason isn’t how much I know, but what I do when I’m ignorant. The most important thing I’ve learned is a principle‑based way of life that helps me discover truth and act on it.” – Ray Dalio

In everyday development and design, we constantly face choices; I ask myself what principles underlie each decision.

Many software design principles are abstract and hard to apply consistently, so we need concrete, scenario‑specific rules that are easy to understand and follow.

1 Common Principles Summary

1.1 Layered Design Principles

Single‑Direction Dependency Principle

Higher layers may depend on lower layers, but reverse dependencies are prohibited.

In our financial‑solution department, the platform layer must not depend on the business product layer. Dependencies within the same platform layer are allowed but minimized.

Convert system dependencies into data dependencies.

Use interface dependencies via SPI; avoid unless necessary.

Decouple through event mechanisms.

No Circular Dependency Principle

Design should minimize inter‑system dependencies and avoid circular calls.

In micro‑service architectures, circular calls cause deployment and release issues.

Avoid Cross‑Layer Calls Principle

Higher layers must not invoke lower‑level implementations directly.

Cross‑layer calls expose low‑level details, making refactoring costly, as seen when façade services bypass domain services to call DAOs directly.

Single Responsibility Principle

Introduced by Robert C. Martin, a class should have only one reason to change.

In our financial network system we split the architecture into an integration layer (handling institution interfaces) and a product‑extension layer (exposing standard APIs). Adding a new institution should only affect the integration layer, while adding a new product should only affect the product‑extension layer.

Data Redundancy Principle

Architecture should minimize data redundancy.

We enforce minimal required parameters in Javadoc, perform early validation, and ensure cache consistency when data changes.

2 Quality Attribute Principles

Data Security

Storage security: encrypt sensitive data, mask logs.

Transmission security: encrypt channels, transmit only necessary fields.

Output display: prevent horizontal privilege escalation on the front end.

Asset‑Loss Prevention

Verifiable and monitorable data models for stable upstream/downstream relationships.

Circuit‑breaker for critical loss‑prone links.

Concurrency Control

Pessimistic lock: one lock, two checks, three updates.

Optimistic lock: updates must occur within a transaction.

Hotspot Issues

Avoid traffic skew that overloads a single machine, table, or database.

We forecast 3‑5 years of business scale during design to prevent overload.

Data Skew

Sharding rules must ensure even data distribution and avoid single‑database or single‑table hotspots.

Past incidents taught us to design storage layers with balanced distribution.

Performance Principle

High‑load links should be testable (stress‑testable).

Frequent promotional events require re‑engineering of test pipelines.

Transaction Control Principles

Prefer programmatic transactions for better control.

Maintain order consistency for updates (strong vs. eventual consistency).

Avoid remote calls inside transactions.

Consistency Principles

Distinguish system call errors from business failures.

Support retry mechanisms for interrupted executions.

Async processing must include verification and monitoring for data consistency.

2 API Design Principles

1 Horizontal Privilege Control

API design must guard against horizontal privilege escalation.

Each layer—from front end to back end—performs privilege checks.

2 Idempotency Control

Callers must provide idempotency parameters; identical requests must remain idempotent.

Our team treats idempotency as a non‑negotiable standard.

3 Compatibility Principle

API upgrades must remain compatible with older versions.

We avoid enums and primitive types in parameters and design APIs with forward‑looking, generic structures.

3 Summary

This article presents a collection of practical design principles distilled from real‑world financial system projects. By concretizing abstract rules, teams can reach consensus quickly, ensure architectural solutions are implementable, and avoid repeating past mistakes.