agentsclimarketplace

System design

Skill iceflower/agent-skills/system-design

Agent Skills 오픈 표준 기반 AI 코딩 에이전트용 스킬 컬렉션 (Java, Kotlin, Spring, NestJS, K8s, Terraform, GraphQL, gRPC, OpenTelemetry, a11y, i18n 등 60개)

Install
npx -y skills add iceflower/agent-skills --skill system-design

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Large-scale system design patterns including database architecture, caching, CDN, stateless design, message queues, consistent hashing, and rate limiting. Covers CAP theorem, eventual consistency, sharding strategies, replication factor, read replica configuration, and system stability patterns (circuit breaker, bulkhead, backpressure). Includes distributed systems patterns: data replication, partitioning, consensus, distributed time (Lamport clock, hybrid clock), cluster management (lease, gossip, state watch), and network communication patterns. Use when designing scalable system architectures, evaluating consistency vs availability trade-offs, planning data partitioning and replication strategies, or implementing distributed systems patterns.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

13.0 KB, as published. Nobody here has run it

System Design Patterns

Large-scale system design principles and distributed systems patterns. Use when designing scalable architectures, preparing for system design interviews, evaluating system architecture, or implementing distributed systems.

Note: This document synthesizes system design concepts from various sources including industry best practices, technical blogs, community knowledge, and "Patterns of Distributed Systems" by Unmesh Joshi.

Design Discussion Framework

General Approach

When approaching a system design problem:

  1. Understand Requirements

    • Clarify functional requirements
    • Define scope and constraints
    • Identify non-functional requirements (scale, latency)
  2. Create High-Level Design

    • Sketch core components
    • Show data flow between components
    • Discuss key decisions
  3. Detail Components

    • Deep dive on critical components
    • Discuss trade-offs
    • Handle edge cases
  4. Review and Improve

    • Identify bottlenecks
    • Suggest optimizations
    • Consider failure scenarios

1. Scalability Fundamentals

Vertical vs Horizontal Scaling

AspectVertical (Scale Up)Horizontal (Scale Out)
ApproachBigger serverMore servers
LimitHardware maxTheoretically unlimited
CostExpensive at high endLinear growth
ComplexitySimpleRequires load balancing
FailureSingle pointGraceful degradation

Load Balancer

Distribute traffic across servers.

         ┌──────────────┐
         │Load Balancer │
         │  (Public IP) │
         └──────┬───────┘
          ┌─────┼─────┐
          ▼     ▼     ▼
      ┌─────┐ ┌─────┐ ┌─────┐
      │ Svr1│ │ Svr2│ │ Svr3│
      └─────┘ └─────┘ └─────┘

Algorithms:

  • Round-robin
  • Weighted round-robin
  • Least connections
  • IP hash
  • Health-check based

Layer Selection:

  • Layer 4 (Transport): TCP/UDP routing
  • Layer 7 (Application): HTTP path/header routing

2. Database Architecture

RDBMS vs NoSQL

FeatureRDBMSNoSQL
SchemaFixedFlexible
ScalingVerticalHorizontal
ACIDFullVaries
JoinsNativeLimited
Use CaseStructured dataUnstructured, high volume

See references/scalability-and-data.md for detailed replication, sharding, caching, CDN, stateless architecture, data center, consistent hashing, rate limiting, key-value store, and ID generation patterns.


3. Caching Strategies

Cache Eviction Policies

PolicyDescriptionUse Case
LRULeast Recently UsedGeneral purpose
LFULeast Frequently UsedPopular items matter
FIFOFirst In First OutSimple needs
TTLTime To LiveFreshness matters

Cache Considerations

  • Consistency: Cache may be stale
  • TTL: Balance freshness vs load
  • Penetration: Handle missing keys
  • Avalanche: Stagger expirations
  • Breakdown: Lock hot keys

4. Message Queue

Decouple components with async messaging.

Producer                 Queue                   Consumer
   │                      │                        │
   │─── Message ─────────▶│                        │
   │                      │─── Message ───────────▶│
   │                      │                        │
   │                      │─── Message ───────────▶│
   │─── Message ─────────▶│                        │

Message Queue Benefits

  • Decoupling: Producer doesn't need consumer details
  • Buffering: Handle traffic spikes
  • Scalability: Add more consumers
  • Reliability: Persistent messages

Use Cases

  • Async processing
  • Background jobs
  • Event notification
  • Log aggregation

5. Distributed Systems Core Challenges

ChallengeDescription
Network LatencyCommunication between nodes takes time
Partial FailureSome nodes fail while others continue
Clock DriftNo synchronized clock across nodes
ConsistencyData may differ across replicas
ConcurrencyMultiple operations on same data

6. Distributed Systems Patterns Overview

30 patterns organized in 5 categories. See referenced files for detailed descriptions and code examples.

Replication Patterns (16 patterns)

See references/replication-patterns.md for full details.

#PatternPurpose
1Write-Ahead LogPersist operations before applying
2Segmented LogSplit log into manageable segments
3Low-Water MarkTrack minimum log index for recovery
4Leader-FollowerSingle coordinator manages cluster
5HeartbeatDetect node failures
6QuorumRequire majority agreement
7Generation ClockTrack leadership epochs
8High-Water MarkTrack max replicated log index
9PaxosDistributed consensus
10Replicated LogConsensus-based log replication (Raft)
11Single-Socket ChannelSequential request processing
12Request QueueConcurrent requests with ordering
13Idempotent ReceiverHandle duplicate requests safely
14Follower ReadServe reads from followers
15Versioned ValueStore multiple versions per key
16Version VectorTrack causality across replicas

Partition Patterns (3 patterns)

See references/partition-patterns.md for full details.

#PatternPurpose
17Fixed PartitionsPre-create fixed number of partitions
18Key-Range PartitionPartition by key ranges
19Two-Phase CommitAtomic commit across partitions

Time Patterns (3 patterns)

See references/time-and-cluster.md for full details.

#PatternPurpose
20Lamport ClockLogical timestamps for ordering
21Hybrid ClockCombine physical and logical clocks
22Clock Bound WaitHandle clock uncertainty

Cluster Management Patterns (5 patterns)

See references/time-and-cluster.md for full details.

#PatternPurpose
23Consistency CoreCentralized metadata management
24LeaseTime-based exclusive access
25State WatchReact to state changes in cluster
26Gossip DisseminationSpread info via random peer comm
27Emergent LeaderDecentralized leader election

Network Communication Patterns (3 patterns)

See references/network-patterns.md for full details.

#PatternPurpose
28Single-Socket Ch.Maintain single connection for ordering
29Batched RequestsSend multiple requests in single message
30Request PipelineSend requests without waiting responses

7. Latency Reference Numbers

Source: Based on "Numbers Every Programmer Should Know" by Jeff Dean (Google). Actual values vary by hardware.

OperationApproximate Latency
L1 cache reference~1 ns
L2 cache reference~4 ns
Mutex lock/unlock~17 ns
Main memory reference~100 ns
SSD random read~16 us
Read 1MB from SSD~50 us
Network round-trip same DC~500 us
Disk seek~3 ms

8. Capacity Estimation Example

Example calculation (adjust numbers for your use case):

Daily Active Users: 500K
Requests per user: 80/day
QPS = 500K * 80 / 86400 ≈ 460 QPS
Peak QPS = QPS * 2-3 ≈ 1,400 QPS

Storage:
Per user: 500KB/day
Daily: 500K * 500KB = 250GB
With replication (3x): 750GB/day

9. System Design Patterns Summary

ProblemPattern
Single server bottleneckLoad balancer + horizontal scaling
Database overloadCaching, read replicas
Large datasetSharding, partitioning
Geographic latencyCDN, multi-DC
Session managementExternal session store
Service couplingMessage queue
Hot partitionsConsistent hashing with virtual nodes
Traffic spikesRate limiting, circuit breaker
Data persistenceWAL, Segmented Log
High availabilityLeader-Follower, Quorum
Failure detectionHeartbeat, Generation Clock
ConsistencyPaxos, Raft (Replicated Log)
Read scalabilityFollower Read, Versioned Value
Data partitioningFixed Partitions, Key-Range
Cross-partition transactions2PC
Time orderingLamport Clock, Hybrid Clock
Cluster coordinationConsistency Core, Lease, Gossip

10. Design Discussion Checklist

Clarify Requirements

  • Functional requirements
  • Non-functional requirements (scale, latency)
  • Out of scope items

Define Constraints

  • Traffic estimates (QPS)
  • Storage estimates
  • Bandwidth estimates

Design Components

  • Client → API layer
  • API layer → Service layer
  • Service layer → Data layer
  • Cache strategy
  • Async processing (if needed)

Deep Dive Topics

  • Database schema
  • API design
  • Scalability approach
  • Failure handling
  • Monitoring/logging

Related Skills

  • api-design: REST API design principles
  • messaging: Message broker patterns (Kafka, RabbitMQ)
  • caching: Cache implementation patterns, distributed cache patterns
  • spring-framework: Reactive distributed clients (WebFlux)
  • k8s-workflow: Container orchestration patterns

References

  • Designing Data-Intensive Applications by Martin Kleppmann
  • Patterns of Distributed Systems by Unmesh Joshi
  • Building Secure and Reliable Systems by Google
  • Raft paper by Diego Ongaro and John Ousterhout
  • Various technical blogs, distributed systems literature, and community resources
  • For system stability patterns, see references/stability-patterns.md

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.