Key Recommendations for System Architecture Design

Recently I was responsible for the system architecture design of a project. After presenting an initial draft and receiving extensive criticism from the chief scientist, I realized many improvements are needed and welcomed further critique.

1. Do not consider platform APIs early The first version included a public API, but its purpose was limited and future extensions are simple, so omitting it reduces system complexity.

2. Design must be more detailed and decisive technology selection is required System design is not merely a restatement of requirements; as an architect, you must make early decisions on critical technology choices.

3. Call relationships must not form triangular dependencies The original diagram did not clearly indicate master‑slave relationships, leading to apparent triangular dependencies. The direction of calls should be explicit, with the initiator at the arrow start.

4. Identify program modules at the design level It must be clear which subsystem is a command‑line program, a system service, or a web service.

5. The system is a network hub (star) rather than a layered system Layered architectures are suitable for fully encapsulated lower layers, whereas a star‑shaped hub cannot be described as layered.

6. Separate business logic into a business layer; task system must be business‑agnostic Business‑related modules should be isolated, and task dispatch must occur in the business layer.

7. After splitting computation, intermediate results should not be recorded directly but aggregated by a scheduler (transaction, crash‑resilience) Intermediate task modules need to consider transaction safety and recovery from crashes.

8. Compute system and external management system can be abstracted as compute units

9. Decouple scheduling system from business using database isolation

10. Configuration information should be reflected in the architecture design

11. All call relationships must be explicit

12. Reference state > reference history

13. Keep all systems as passive as possible This reduces coupling and development complexity.

14. Video meta‑computation is indivisible and does not require distributed cluster computing

15. Logs must be discardable; otherwise they become business data This is a classic principle.

16. Automatic upgrade of compute nodes can be designed from the start