Business System Design Method

1. Start from the Business Invariant

Before choosing Redis, Kafka, sharding, or microservices, identify what must remain true.

Examples:

• an order is charged at most once;
• inventory never goes below the accepted oversell bound;
• a user sees their own successful write;
• an event may be delayed but must eventually be processed.

The invariant determines which failures are tolerable.

2. Clarify Requirements

Separate:

• functional flows;
• latency/availability/durability SLOs;
• consistency requirements;
• security/compliance;
• traffic and data scale;
• operational constraints.

Avoid designing for an unspecified phrase such as “high concurrency.”

3. Estimate Scale

Quantify rough orders of magnitude:

• peak and average QPS;
• read/write ratio;
• payload size;
• daily data growth and retention;
• fan-out;
• concurrency and connection count.

Back-of-the-envelope estimates are enough to reject impossible architectures early.

4. Model Data and Ownership

Identify:

• source of truth;
• keys and access paths;
• transaction boundaries;
• lifecycle/retention;
• partition key;
• derived/cache/search copies.

Every duplicate copy creates a synchronization problem that must have a recovery path.

5. Draw the Critical Path

For the user-visible request, list each network hop and synchronous dependency. Then ask:

• can work be cached?
• can work become asynchronous?
• can a dependency be removed from the critical path?
• what happens when each dependency is slow rather than completely down?

6. Design Failure Handling

For each remote call define:

• timeout;
• retry policy and idempotency;
• circuit breaking/load shedding;
• fallback/degradation;
• observability.

For stored state define backup, replay, rebuild, and migration behavior.

7. Add Complexity Only for a Measured Need

A design is not better because it contains more infrastructure. Prefer the smallest architecture whose failure semantics and capacity satisfy the requirements, then leave clear scaling boundaries.