backend-architect

Name: backend-architect
Author: tranhieutt

69stars41forks

How to install backend-architect?

tranhieutt/software_development_department/backend-architect

$npx -y skills add tranhieutt/software_development_department --skill backend-architect

Installs into the current project.

Summary

Designs scalable backend architectures covering microservices, event-driven systems, API gateways, and data stores. Use when designing a backend system or when the user mentions backend architecture, scalability, or distributed systems.

Files · 1

View on GitHub

SKILL.md

1	# Backend Architect
2
3	## Workflow
4
5	1. Capture requirements: Domain context, use cases, NFRs (scale, latency, consistency)
6	2. Define service boundaries: DDD bounded contexts, service decomposition
7	3. Design API contracts: REST/GraphQL/gRPC with versioning strategy
8	4. Plan communication: Sync (REST, gRPC) vs async (queues, events)
9	5. Build in resilience: Circuit breakers, retries, timeouts, graceful degradation
10	6. Design observability: structured logging, RED metrics, distributed tracing
11	7. Security: Auth/Z strategy, rate limiting, secrets management
12	8. Caching: Layer strategy (app → API → CDN) with invalidation plan
13	9. Document: Service diagram (Mermaid), ADRs, trade-offs
14
15	## API design decision matrix
16
17	\| Use case \| Protocol \| Reason \|
18	\|---\|---\|---\|
19	\| Standard CRUD API \| REST \| Widest tooling support \|
20	\| Client queries complex data \| GraphQL \| Reduces over-fetching \|
21	\| Internal service-to-service \| gRPC \| Typed contracts, low latency \|
22	\| Real-time bidirectional \| WebSocket \| Full duplex \|
23	\| Server push (one-way) \| SSE \| Simpler than WS for unidirectional \|
24	\| High-volume async work \| SQS/Kafka \| Decoupling, retry, backpressure \|
25
26	## Service boundary rules (non-obvious)
27
28	- Bounded context = 1 database — shared DB across services creates hidden coupling; eventual consistency is the price of independence
29	- Sync calls create latency chains — A → B → C means P99(A) = P99(A) + P99(B) + P99(C); use async for non-blocking flows
30	- Saga over 2PC — distributed transactions via saga (choreography or orchestration); 2PC blocks and creates distributed deadlocks
31	- Stateless for horizontal scale — session state in Redis/DynamoDB, not in memory
32	- Database per service, not schema per service — separate schemas in shared DB = shared schema migrations = coupling still exists
33
34	## Resilience patterns (always include these)
35
36	```
37	Circuit Breaker: CLOSED → [failures > threshold] → OPEN → [timeout] → HALF-OPEN → [success] → CLOSED
38	Retry: exponential backoff with jitter — base_delay * 2^attempt + random(0, base_delay)
39	Timeout: always set; propagate deadline via context/headers
40	Bulkhead: separate thread pools per dependency; one slow dep shouldn't starve others
41	Idempotency: every mutating operation needs idempotency key; store result, return on duplicate
42	```
43
44	## Observability essentials
45
46	```
47	Logs: structured JSON, always include: traceId, userId, duration, status
48	Metrics (RED): Rate (req/s), Errors (%), Duration (p50/p95/p99)
49	Traces: OpenTelemetry → Jaeger/Tempo; trace every cross-service call
50	Alerts: error rate > 1%, p99 latency > SLO, queue depth > threshold
51	```
52
53	## Caching strategy
54
55	\| Layer \| Tool \| Pattern \| Invalidation \|
56	\|---\|---\|---\|---\|
57	\| App \| Redis \| Cache-aside \| TTL + event-driven \|
58	\| API \| CDN (CloudFront) \| Read-through \| Cache-Control headers \|
59	\| DB reads \| Read replica \| Direct query \| N/A (replica lag) \|
60
61	Cache-aside rule: read → cache miss → DB → cache set → return. Never write to cache directly on writes — let TTL or event invalidate.
62
63	## Auth patterns
64
65	- User auth: OAuth2 + OIDC, JWT access token (15 min TTL) + refresh token (7 days, rotated)
66	- Service-to-service: mTLS or signed JWT with short expiry; never share user tokens between services
67	- API keys: Hash on storage (SHA-256), include key prefix in metadata for lookup
68
69	## Deliver
70
71	- Service diagram (Mermaid) showing communication patterns + boundaries
72	- API contract excerpt (OpenAPI or Protobuf)
73	- Auth/Z strategy
74	- Resilience patterns per dependency
75	- Caching plan with invalidation strategy
76	- Tech recommendations with explicit rationale
77	- ADR for each major decision
78
79	## Scope boundaries
80
81	- Database schema design → `database-architect`
82	- Infrastructure + cloud services → `cloud-architect`
83	- Comprehensive security audit → `security-auditor`
84	- System-wide performance optimization → `performance-engineer`

People who liked this also viewed

6 picks

Type

backend-architect

69stars41forks

View on GitHub

How to install backend-architect?

tranhieutt/software_development_department/backend-architect

$npx -y skills add tranhieutt/software_development_department --skill backend-architect

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Backend Architect
2
3	## Workflow
4
5	1. Capture requirements: Domain context, use cases, NFRs (scale, latency, consistency)
6	2. Define service boundaries: DDD bounded contexts, service decomposition
7	3. Design API contracts: REST/GraphQL/gRPC with versioning strategy
8	4. Plan communication: Sync (REST, gRPC) vs async (queues, events)
9	5. Build in resilience: Circuit breakers, retries, timeouts, graceful degradation
10	6. Design observability: structured logging, RED metrics, distributed tracing
11	7. Security: Auth/Z strategy, rate limiting, secrets management
12	8. Caching: Layer strategy (app → API → CDN) with invalidation plan
13	9. Document: Service diagram (Mermaid), ADRs, trade-offs
14
15	## API design decision matrix
16
17	\| Use case \| Protocol \| Reason \|
18	\|---\|---\|---\|
19	\| Standard CRUD API \| REST \| Widest tooling support \|
20	\| Client queries complex data \| GraphQL \| Reduces over-fetching \|
21	\| Internal service-to-service \| gRPC \| Typed contracts, low latency \|
22	\| Real-time bidirectional \| WebSocket \| Full duplex \|
23	\| Server push (one-way) \| SSE \| Simpler than WS for unidirectional \|
24	\| High-volume async work \| SQS/Kafka \| Decoupling, retry, backpressure \|
25
26	## Service boundary rules (non-obvious)
27
28	- Bounded context = 1 database — shared DB across services creates hidden coupling; eventual consistency is the price of independence
29	- Sync calls create latency chains — A → B → C means P99(A) = P99(A) + P99(B) + P99(C); use async for non-blocking flows
30	- Saga over 2PC — distributed transactions via saga (choreography or orchestration); 2PC blocks and creates distributed deadlocks
31	- Stateless for horizontal scale — session state in Redis/DynamoDB, not in memory
32	- Database per service, not schema per service — separate schemas in shared DB = shared schema migrations = coupling still exists
33
34	## Resilience patterns (always include these)
35
36	```
37	Circuit Breaker: CLOSED → [failures > threshold] → OPEN → [timeout] → HALF-OPEN → [success] → CLOSED
38	Retry: exponential backoff with jitter — base_delay * 2^attempt + random(0, base_delay)
39	Timeout: always set; propagate deadline via context/headers
40	Bulkhead: separate thread pools per dependency; one slow dep shouldn't starve others
41	Idempotency: every mutating operation needs idempotency key; store result, return on duplicate
42	```
43
44	## Observability essentials
45
46	```
47	Logs: structured JSON, always include: traceId, userId, duration, status
48	Metrics (RED): Rate (req/s), Errors (%), Duration (p50/p95/p99)
49	Traces: OpenTelemetry → Jaeger/Tempo; trace every cross-service call
50	Alerts: error rate > 1%, p99 latency > SLO, queue depth > threshold
51	```
52
53	## Caching strategy
54
55	\| Layer \| Tool \| Pattern \| Invalidation \|
56	\|---\|---\|---\|---\|
57	\| App \| Redis \| Cache-aside \| TTL + event-driven \|
58	\| API \| CDN (CloudFront) \| Read-through \| Cache-Control headers \|
59	\| DB reads \| Read replica \| Direct query \| N/A (replica lag) \|
60
61	Cache-aside rule: read → cache miss → DB → cache set → return. Never write to cache directly on writes — let TTL or event invalidate.
62
63	## Auth patterns
64
65	- User auth: OAuth2 + OIDC, JWT access token (15 min TTL) + refresh token (7 days, rotated)
66	- Service-to-service: mTLS or signed JWT with short expiry; never share user tokens between services
67	- API keys: Hash on storage (SHA-256), include key prefix in metadata for lookup
68
69	## Deliver
70
71	- Service diagram (Mermaid) showing communication patterns + boundaries
72	- API contract excerpt (OpenAPI or Protobuf)
73	- Auth/Z strategy
74	- Resilience patterns per dependency
75	- Caching plan with invalidation strategy
76	- Tech recommendations with explicit rationale
77	- ADR for each major decision
78
79	## Scope boundaries
80
81	- Database schema design → `database-architect`
82	- Infrastructure + cloud services → `cloud-architect`
83	- Comprehensive security audit → `security-auditor`
84	- System-wide performance optimization → `performance-engineer`

People who liked this also viewed

6 picks

Type