Unlocking Backend Reliability: Lessons from 1号店’s Advanced Logging System

Recently I read an article about the architectural evolution of 1号店, and the most impressive part was its highly refined logging system, which many large and small companies still lack despite its importance as a thinking framework.

Initially, 1号店 used a simple MVC architecture where the controller handled business logic and database interactions, offering low cost and fast response. As business complexity and team size grew, this tightly coupled structure became a bottleneck, increasing code conflicts, error rates, and slowing feature delivery, prompting a shift toward service‑oriented architecture.

The first step of service‑ification at 1号店 focused on monitoring and problem localization, recognizing that logs are the foundation for early issue detection and rapid debugging.

For example, a single order‑placement API defines 135 error codes; to date, 50‑60 distinct codes have been triggered, meaning that 50‑60 problematic or unreasonable scenarios have been captured and corrected, spanning business logic, program bugs, and poorly defined codes.

Even extremely rare errors become traceable through logs; after nearly two years of operation, an unexpected error code surfaced for a seldom‑encountered business scenario, allowing immediate pinpointing of the issue.

The design principles of 1号店’s logging system are:

Persist logs in a database.

Classify and hierarchy‑organize logs with unique error codes to enable instant location and multi‑dimensional monitoring.

An example error code is GOS-10111001. Its structure consists of three groups:

First three digits represent the service name (e.g., 101 for createOrder ).

Next two digits indicate the error type:

1 – System error

2 – Application error (frontend parameter error)

3 – Business error (service‑specific)

4 – Dependency error (third‑party service failure)

5 – Interaction reminder (non‑error business logic, e.g., out‑of‑stock)

99 – Unknown exception

Last three digits detail the specific issue (e.g., 001 for “parameter is empty”).

This systematic approach ensures that bugs, no matter how deep or infrequent, can be quickly identified and resolved, turning logs into a persistent, proactive defense mechanism.