菜单
Use when designing, implementing, or debugging distributed services — architecture choices, consistency trade-offs, fault tolerance, coordination, naming, and security for multi-node systems.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ayush488-glitch/agentic-swe-kit --skill distributed-systems命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
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.
基于 SOC 职业分类
正在显示 SKILL.md
| 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.