design-system

Name: design-system
Author: tranhieutt

69stars41forks

How to install design-system?

tranhieutt/software_development_department/design-system

$npx -y skills add tranhieutt/software_development_department --skill design-system

Installs into the current project.

Summary

Decomposes a product concept into architectural components, domain systems, data models, and integration boundaries. Use when starting system architecture or when the user mentions system design or component breakdown.

Files · 1

View on GitHub

SKILL.md

1	# System Design
2
3	## Phase 1: Clarify requirements (always do this first)
4
5	Ask before designing:
6	1. Scale: How many users/requests/day? Read-heavy or write-heavy?
7	2. Consistency: Strong (banking) or eventual (social feed)?
8	3. Availability target: 99.9% (8.7h/yr downtime) or 99.99% (52min/yr)?
9	4. Latency budget: p99 < 100ms? < 1s?
10	5. Geography: Single region or multi-region?
11
12	## Capacity estimation shortcuts
13
14	```
15	1M users/day active → ~12 req/s avg, ~120 req/s peak (10x)
16	1KB per request → 1M req/day = ~1GB/day = ~365GB/year
17	Read:write ratio 10:1 (typical social) → optimize read path first
18	1 server handles ~1000 req/s (rule of thumb for I/O-bound services)
19	```
20
21	## Component breakdown template
22
23	```
24	Client layer → Web / Mobile / API consumers
25	CDN → Static assets, edge caching
26	API Gateway → Rate limiting, auth, routing, SSL termination
27	Services → Domain-specific services (User, Order, Payment, Notification)
28	Cache → Redis for hot data (sessions, rate limits, computed results)
29	Database → Primary DB + Read replicas
30	Message queue → Async operations, event-driven decoupling
31	Storage → Object storage for files (S3/GCS)
32	Monitoring → Metrics, logs, traces, alerts
33	```
34
35	## Database selection guide
36
37	\| Need \| Choose \|
38	\|---\|---\|
39	\| ACID transactions, relations \| PostgreSQL \|
40	\| High-scale document store \| MongoDB \|
41	\| Key-value, cache, pub/sub \| Redis \|
42	\| Time-series data \| TimescaleDB / InfluxDB \|
43	\| Graph relationships \| Neo4j \|
44	\| Full-text search \| Elasticsearch \|
45	\| Analytical/OLAP \| ClickHouse / BigQuery \|
46
47	## Caching strategies
48
49	```
50	Cache-aside (read): App checks cache → miss → DB → write to cache
51	Write-through: Write to cache AND DB simultaneously (consistent, slower writes)
52	Write-behind: Write to cache → async flush to DB (fast writes, risk of loss)
53	Read-through: Cache handles DB reads automatically
54
55	TTL guidelines:
56	- Sessions: 15-30 min
57	- User profile: 5 min
58	- Product catalog: 1 hour
59	- Config/settings: 24 hours
60	```
61
62	## Message queue patterns
63
64	```
65	When to use queues:
66	✓ Async processing (email, PDF generation, notifications)
67	✓ Rate-limiting downstream services
68	✓ Decoupling services (order → payment → shipping)
69	✓ Fan-out (1 event → multiple consumers)
70
71	Queue selection:
72	- RabbitMQ: complex routing, request-reply, low latency
73	- Kafka: high throughput, event log/replay, stream processing
74	- SQS: managed, simple, AWS-native, at-least-once delivery
75	- Redis Streams: lightweight, same infra as cache
76	```
77
78	## API design decisions
79
80	```
81	REST: Standard CRUD, simple clients, team familiarity (default choice)
82	GraphQL: Multiple clients with different data needs, reduce over-fetching
83	gRPC: Internal service-to-service, binary protocol, streaming needed
84	WebSocket: Real-time bidirectional (chat, live updates, collaborative tools)
85	```
86
87	## Scaling patterns
88
89	```
90	Vertical (scale up): More CPU/RAM — quick, limited ceiling
91	Horizontal (scale out): More instances — requires stateless services
92	Database read replicas: Offload read traffic (good for 80%+ read workloads)
93	Database sharding: Shard by user_id, geography — last resort, complex
94	CQRS: Separate read/write models — when read/write patterns diverge heavily
95	```
96
97	## Common design mistakes
98
99	\| Mistake \| Better approach \|
100	\|---\|---\|
101	\| Over-engineering for scale you don't have \| Start monolith, extract services at clear pain points \|
102	\| Synchronous calls to all dependencies \| Use async queues for non-critical paths \|
103	\| No caching strategy \| Cache at API layer + DB query results \|
104	\| Storing sessions in DB \| Use Redis; DB sessions don't scale horizontally \|
105	\| Single point of failure \| Redundancy at every critical layer \|

People who liked this also viewed

6 picks

Type

design-system

69stars41forks

View on GitHub

How to install design-system?

tranhieutt/software_development_department/design-system

$npx -y skills add tranhieutt/software_development_department --skill design-system

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# System Design
2
3	## Phase 1: Clarify requirements (always do this first)
4
5	Ask before designing:
6	1. Scale: How many users/requests/day? Read-heavy or write-heavy?
7	2. Consistency: Strong (banking) or eventual (social feed)?
8	3. Availability target: 99.9% (8.7h/yr downtime) or 99.99% (52min/yr)?
9	4. Latency budget: p99 < 100ms? < 1s?
10	5. Geography: Single region or multi-region?
11
12	## Capacity estimation shortcuts
13
14	```
15	1M users/day active → ~12 req/s avg, ~120 req/s peak (10x)
16	1KB per request → 1M req/day = ~1GB/day = ~365GB/year
17	Read:write ratio 10:1 (typical social) → optimize read path first
18	1 server handles ~1000 req/s (rule of thumb for I/O-bound services)
19	```
20
21	## Component breakdown template
22
23	```
24	Client layer → Web / Mobile / API consumers
25	CDN → Static assets, edge caching
26	API Gateway → Rate limiting, auth, routing, SSL termination
27	Services → Domain-specific services (User, Order, Payment, Notification)
28	Cache → Redis for hot data (sessions, rate limits, computed results)
29	Database → Primary DB + Read replicas
30	Message queue → Async operations, event-driven decoupling
31	Storage → Object storage for files (S3/GCS)
32	Monitoring → Metrics, logs, traces, alerts
33	```
34
35	## Database selection guide
36
37	\| Need \| Choose \|
38	\|---\|---\|
39	\| ACID transactions, relations \| PostgreSQL \|
40	\| High-scale document store \| MongoDB \|
41	\| Key-value, cache, pub/sub \| Redis \|
42	\| Time-series data \| TimescaleDB / InfluxDB \|
43	\| Graph relationships \| Neo4j \|
44	\| Full-text search \| Elasticsearch \|
45	\| Analytical/OLAP \| ClickHouse / BigQuery \|
46
47	## Caching strategies
48
49	```
50	Cache-aside (read): App checks cache → miss → DB → write to cache
51	Write-through: Write to cache AND DB simultaneously (consistent, slower writes)
52	Write-behind: Write to cache → async flush to DB (fast writes, risk of loss)
53	Read-through: Cache handles DB reads automatically
54
55	TTL guidelines:
56	- Sessions: 15-30 min
57	- User profile: 5 min
58	- Product catalog: 1 hour
59	- Config/settings: 24 hours
60	```
61
62	## Message queue patterns
63
64	```
65	When to use queues:
66	✓ Async processing (email, PDF generation, notifications)
67	✓ Rate-limiting downstream services
68	✓ Decoupling services (order → payment → shipping)
69	✓ Fan-out (1 event → multiple consumers)
70
71	Queue selection:
72	- RabbitMQ: complex routing, request-reply, low latency
73	- Kafka: high throughput, event log/replay, stream processing
74	- SQS: managed, simple, AWS-native, at-least-once delivery
75	- Redis Streams: lightweight, same infra as cache
76	```
77
78	## API design decisions
79
80	```
81	REST: Standard CRUD, simple clients, team familiarity (default choice)
82	GraphQL: Multiple clients with different data needs, reduce over-fetching
83	gRPC: Internal service-to-service, binary protocol, streaming needed
84	WebSocket: Real-time bidirectional (chat, live updates, collaborative tools)
85	```
86
87	## Scaling patterns
88
89	```
90	Vertical (scale up): More CPU/RAM — quick, limited ceiling
91	Horizontal (scale out): More instances — requires stateless services
92	Database read replicas: Offload read traffic (good for 80%+ read workloads)
93	Database sharding: Shard by user_id, geography — last resort, complex
94	CQRS: Separate read/write models — when read/write patterns diverge heavily
95	```
96
97	## Common design mistakes
98
99	\| Mistake \| Better approach \|
100	\|---\|---\|
101	\| Over-engineering for scale you don't have \| Start monolith, extract services at clear pain points \|
102	\| Synchronous calls to all dependencies \| Use async queues for non-critical paths \|
103	\| No caching strategy \| Cache at API layer + DB query results \|
104	\| Storing sessions in DB \| Use Redis; DB sessions don't scale horizontally \|
105	\| Single point of failure \| Redundancy at every critical layer \|

People who liked this also viewed

6 picks

Type