メニュー
Use when designing, implementing, or debugging distributed services — architecture choices, consistency trade-offs, fault tolerance, coordination, naming, and security for multi-node systems.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | distributed-systems |
| description | Use when designing, implementing, or debugging distributed services — architecture choices, consistency trade-offs, fault tolerance, coordination, naming, and security for multi-node systems. |
| version | 1.0.0 |
| author | Ayush Singh |
| license | MIT |
| platforms | ["macos","linux"] |
| metadata | {"hermes":{"tags":["distributed-systems","consistency","fault-tolerance","coordination","replication","networking","security"],"related_skills":["data-systems-engineering","modular-architecture","swe-foundations"]}} |
A distributed system is a collection of autonomous computing elements that appears to its users as a single coherent system — maintaining that illusion is the core engineering challenge.
There is no global clock. Never assume synchronized time across nodes for ordering events. Use Lamport clocks or vector timestamps to establish causal ordering instead.
Distribution transparency has a performance price and can never be fully achieved. Explicitly decide which transparency properties (location, replication, failure) you are willing to expose to users versus hide.
Redundancy is the only path to fault tolerance. A system that cannot continue when a node fails is not fault-tolerant — it is merely resilient to luck.
Replacing a component can only be done safely if its interfaces remain untouched. Design components with well-defined required and provided interfaces from the start.
An identifier is not an address. Use location-independent identifiers for entities; never hardcode IPs or hostnames as stable keys. Names that embed location break when things move.
Weaker consistency is cheaper to implement. Sequential consistency is elegant but expensive. Choose the weakest model that still satisfies your correctness requirements (monotonic reads, writes-follow-reads, eventual).
Security must be pervasive, not additive. A single design flaw can render all other security measures useless. Define a security policy before building mechanisms — mechanisms without policy cannot be audited.
Coordination encapsulates synchronization. Mutual exclusion and leader election in distributed systems are always more expensive and more failure-prone than in single-node systems.
By using 2k+1 servers, Paxos achieves k-fault tolerance. Handle arbitrary (Byzantine) failures requires 3k+1 servers. Know which failure model you are designing for before choosing a consensus algorithm.
Epidemic (gossip) protocols are simple, robust, and highly scalable. When you need information dissemination, aggregation, or peer sampling at scale without central coordination, gossip is frequently the best tool.
Access control always follows authentication. Never authorize before identity is verified. Use session keys bootstrapped by public-key cryptography; avoid long-lived shared symmetric keys.
For deeper context, load these wiki pages:
LLM coding agents reliably fail on distributed systems work in three specific ways:
False network assumptions — generated code defaults to treating network calls as local function calls: no timeouts, no retries, no partial-failure handling. Agents should audit every generated remote call against the eight fallacies of distributed computing before finalizing code.
Consistency model blindness — agents default to "strong consistency" without analyzing cost. When generating caching, replication, or coordination logic, agents must explicitly state the consistency model chosen and justify it against the performance and availability requirements.
Security mechanism without security policy — agents generate encryption, token checks, and ACLs without first specifying what the policy is (who can do what to whom). Mechanisms without auditable policy are unverifiable. Agents must define the security policy as a structured artifact before generating any security-related code.
Use when designing, building, evaluating, or operating AI agent systems in production — agent architecture, orchestration patterns, RAG pipelines, evaluation, observability, guardrails, and domain-specific deployment.
Use when starting, reviewing, or building any production-grade software or AI-native system. Orchestrates the full 20-phase production lifecycle, routes to the right domain skills at each phase, and guides the agent through every engineering layer from cognitive design to continuous learning.
Use when designing, evaluating, or debugging data-intensive systems — storage engines, replication, partitioning, transactions, distributed consistency, batch/stream processing, or encoding.
Use when a coding agent must make architectural, quality, or design decisions during implementation — calibrating trade-offs, communicating honestly, and maintaining integrity across iterations.
Use when making dependency management decisions, drawing component boundaries, applying SOLID principles, designing layered architectures, or evaluating whether a structural decision keeps options open vs. locks them in.
Use when designing, reviewing, or building production systems — architecture decisions, integration points, stability patterns, capacity planning, observability, and operations.
