How to Design Technical Solutions with Real Depth and Breadth: Methodologies and Case Studies

1. Demonstrating Breadth and Depth in Technical Solutions

Many engineers feel their designs lack impact; common complaints include overly simple scenarios, low complexity, few highlights, and ordinary designs. These symptoms indicate a need to examine why solutions appear shallow.

Why Solutions Appear Shallow

Often the problem is “addressing the issue without stepping back”. Designers focus on immediate functional points without considering the underlying purpose, value, or broader context, leading to narrow, tree‑only thinking.

A deeper cause is the lack of systematic thinking—seeing only the trees, not the forest—and the absence of a personal methodology to guide analysis and problem‑solving.

2. Characteristics of Breadth and Depth

Breadth refers to the variety and number of components (e.g., expanding a simple coupon system into a full suite of cards, vouchers, points, and cash). Depth reflects the ability to identify hidden problems and devise innovative solutions, such as designing a multi‑stage loss‑prevention mechanism for coupon fraud.

3. Proving a Technical Solution Is Good

When presenting a solution, the reasoning process matters more than the final diagram. Two principles help:

Syllogism : Start with a strong premise—industry benchmarks or standards—then show how your design differs or improves upon them.

Contextual Argument : Adapt the solution to the specific business environment, acknowledging that the optimal industry solution may not fit your constraints.

4. Methodology for Designing Technical Solutions

What Is a Methodology?

A methodology refines individual techniques into a coherent, repeatable process. It combines “methods” (specific actions like caching, load testing) with “theory” (analysis, discussion) to create a systematic approach.

Four Core Methodologies

Essence Theory : Capture the core of a problem in a concise statement (e.g., “limited resources handling massive requests” for high concurrency).

Contradiction Theory : Identify opposing forces (resource vs. request) and seek to balance them.

System Theory : View the problem from multiple dimensions and combine various techniques (caching, network optimization, program optimization, etc.).

Evolution Theory : Design solutions that can evolve over time, addressing primary contradictions first and adapting as new challenges emerge.

5. Case Studies Applying the Methodology

5.1 High‑Concurrency Solution

Problem: Limited resources cannot handle a surge of requests, causing time‑outs.

Analysis: Treat the resource‑request contradiction as a “neutralization” problem—scale resources horizontally, optimize performance, or reduce request volume.

5.2 Asynchronous Processing Solution

Problem: Synchronous calls cause high latency and occasional time‑outs.

Analysis: Abstract asynchronous processing as “temporary storage + deferred execution”. When a message broker is unavailable, alternative storage (e.g., FTP) can be used, demonstrating that the lack of a specific component does not preclude a solution.

5.3 Scalability Solution for Real‑Time Audience Calculation

Problem: Manual development cycle of two weeks for each new real‑time metric.

Analysis: Separate the invariant workflow (data ingestion → transformation → output) from variable business logic. By exposing a UI that generates Flink SQL based on selected parameters, business users can launch new metrics without deep engineering effort.

6. Summary

The article presents a structured approach to technical solution design, combining essence, contradiction, system, and evolution theories, and demonstrates their application through three concrete cases.