【SOP】 Technical Solution

【SOP】 Technical Solution

Primary Designer	Review Date	Review Participants	Review Remarks	Need Re‑review?
XXX	2022‑02‑22	xxx, yyy	Minutes and focus points of the review meeting; whether another review is needed	Yes / No (if multiple reviews, list each on a separate line)

1. Requirement Analysis

Background

Note: Explain using the “Problem – Solution – Value – Measurement” structure. Business goals must be quantified (3–5 items), and non‑goals and success criteria should be clearly defined.

Business Terminology

Note: List only terms relevant to this requirement; keep it concise and clear.

Business Term	Explanation

Reference Documents

Note: Include, but are not limited to, PRD, related documents, reference materials, etc.

Document	Remarks	Product Document

2. System Design

Note: System architecture; service design; interface design (key interfaces must specify type—HTTP, RPC—name, method, description, request/response parameters, authentication, estimated QPS, timeout (ms)). Refer to Apifox API docs. MQ design: if any MQ configuration exists, describe it.

System Architecture

Note: Required if this requirement triggers changes to the system architecture; otherwise optional.

Service Design

Note: Provide details as needed, such as workflow diagrams, sequence diagrams, class diagrams, state‑machine designs, etc.

Internal Interface Design

Note: List key interfaces; detailed specs can be linked to Apifox/Proto.

Interface Type	Interface Name	Method	Description	Auth Required?	Estimated QPS	Timeout (ms)	Idempotency Strategy	Request/Response Docs
HTTP	/keyword/list	POST	Keyword list query	Yes	100	300	userId+ts	Apifox link
RPC	XxxRemoteService.list	Pigeon	Keyword list query	Yes	200	300	Request idempotency key	Interface definition link

Database Design

Note: If DB changes are involved, provide “Change Description / DDL / Index Rationale”. Deletions/abandonments must be synchronized with the data team.

Change Summary

Database	Table	Change Type	Description

Deleted fields / deprecated fields (including important content such as status) must be communicated to the data side.
Deprecated tables (must also be communicated to the data side) – table no longer used.

Table Detail Design

Table Name	Sharding (if any – include sharding key)	Estimated Data Volume (day/week)	CREATE TABLE Statement
	No

Index Design

Change Type	Index	Reason
Add		Explain why the index is needed and the scenario.
Modify		Explain why the change is made and the justification.
Delete		No longer needed; replaced by XXX index, which better supports YYY.

External Interfaces

Note: If none, state “No external dependencies for this iteration”. If present, fill in parameters, SLA, degradation strategy. Request/response examples should be obtained from the counterpart using real production data.

External Interface Identifier (state “None” if not applicable)	Documentation	Interface Name	Call Method	Timeout (ms)	Retryable?	QPS	Auth Required?	TP999	Retry Count	Failure Degradation / Circuit‑Breaker Strategy	Contact
			RPC/HTTP	-	Yes	-	No	-	Yes	-

{{接口名称}}

Sample request payload: (obtain real production data from the relevant party)

Sample response payload: (obtain real production data from the relevant party)

Cache Design

Note: Specify cluster, structure, key format, TTL, data volume and size estimates; indicate fallback and expiration strategies to avoid cache‑penetration or avalanche.

Cluster	Key Format	Structure	TTL	Estimated QPS	Estimated Item Count	Estimated Value Size	Fallback Strategy
	user:{id}:xxx	KV / SET / HASH / LIST / ZSET	Permanent / 1d / 10m		≤1K / 1K‑1M / >1M		Fallback to DB / cache empty value

Configuration Design

Note: List switches, constants, rate limits, thresholds; indicate config type (system / switch / threshold), environment values, and change nature.

Config Key	Data Type	Config Type	Config Value (or example)	Description	Change Nature	Remarks
		System config / Switch	Online: … Offline: …		Add / Update / Delete

Scheduled Task Design

Note: List purpose, trigger rule, parameters, failure handling, and concurrency strategy for all‑node tasks.

Task Name	Trigger	Cron / Interval	Task Parameters	Timeout (ms)	Failure Retry / Compensation
	Single‑node / All‑node	0 0/5 * * * ?			Retry 3 times / manual compensation

MQ Design

Note: Define topic production/consumption parameters, ordering, retry / dead‑letter handling, and idempotency.

Topic	Production QPS	Partitions	Consumer Threads	Ordering	Idempotency	Retry / Dead‑Letter
	1000	4	1	Not required	Custom implementation	Custom implementation (3 retries / dead‑letter queue)

Test Cases

Note: If testing is involved, paste links to the test cases provided by QA.

---

3. Risk Analysis & Design

Monitoring & Alert Configuration

Note: (Optional) Design of internal service monitoring and alerts.

Service Name	Monitoring Item	Alert Type	Alert Config	Remarks
	Failure Count	Transaction / Failure Count Metric: raw value > 0, trigger once per 1‑minute window	P1	Description: high failure count for xxxx function
		Transaction / TP9999 Metric: raw value > 500, trigger 3 times within 5‑minute window	P2	Description: long latency for xxxx function
	Failure Count	Transaction / Failure Count Metric: raw value > 1, trigger once per 1‑minute window	P1	Description: high failure count for xxxx function

Stability Risk Analysis

Compatibility Analysis

Note: (Mandatory) Assess impact of the change on existing business logic, codebase, upstream/downstream systems, and whether stakeholders are informed.

Hotspot Analysis

Note: (Optional) Examine whether caches involved contain large keys or hot keys.

Strong/Weak Dependency Analysis

Note: (Optional) Determine if newly introduced dependencies are strong or weak; for weak dependencies, verify fallback plans so that a failure does not bring down the whole workflow.

Data Consistency Analysis

Note: (Optional) Check for possible inconsistencies between cache and DB.

Resource Capacity Assessment

Note: (Optional) Evaluate the resource consumption (machines, cache, DB, etc.) of the new feature and decide if pre‑emptive scaling is required.

Gray‑Release Plan

Note: (Mandatory) Describe whether the rollout will be controlled by batch releases, feature‑flag configuration, or other mechanisms.

Emergency Plan

Note: (Mandatory) Outline rollback or mitigation steps (e.g., immediate rollback, toggling via Lion or another switch, or alternative measures) if issues arise.

4. Schedule

Note: (Mandatory) Use the template below to align timelines of all stakeholders and fill in the table. Every participant’s dates must be entered.

Date	Phase	Owner	Deliverable
	Requirement Review @A
	Solution Design @A
	Solution v1 Technical Review @A/@B/@C		Review Outcome
	Development A‑E @A/@B		Code + Unit Tests
	Self‑test
	Integration Test @A/@B/@C		Integration Report
	Test Submission @C		Test Report
	Production Release @A		Release Ticket + Regression Test

---

Originally written by Li Wei (李唯_) and published in Chinese on 后端技术栈全书 (Full-Stack Backend Engineering). Translated and adapted for DriftSeas with permission.