Domain patterns for edge computing and offline-first systems — sync protocols, conflict resolution under partition, local-first architecture, constrained resources, intermittent connectivity, and failure modes. Use when designing or evaluating mobile apps, IoT systems, field-deployed software, or any system that must work without reliable network access.
复制安装指令,让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "system-type-edge-offline" 技能: 1. 下载 https://raw.githubusercontent.com/microsoft/amplifier-bundle-systems-design/main/skills/system-type-edge-offline/SKILL.md 2. 保存为 ~/.claude/skills/system-type-edge-offline/SKILL.md 3. 装好后重载技能,告诉我可以用了
Patterns, failure modes, and anti-patterns for systems that operate under intermittent connectivity and constrained resources.
The fundamental assumption shift: the network is not a dependency — it is an optimization. An offline-first system is fully functional without connectivity and becomes better when connectivity is available. This is the opposite of how most systems are built, where the server is the source of truth and the client is a thin rendering layer that breaks the moment the network disappears.
| Model | Description | Network requirement | Complexity | Example |
|---|---|---|---|---|
| Online-only | Server renders everything. Client is a viewport. | Continuous | Lowest | Traditional server-rendered web apps |
| Offline-tolerant | Works online, degrades gracefully offline. Shows cached data, queues writes. | Expected, with brief gaps | Low-medium | Gmail offline mode, Google Maps cached areas |
| Offline-first | Full functionality offline. Sync when connected. Network enhances, does not enable. | Optional, intermittent | High | Notion mobile, Field Service apps, CouchDB/PouchDB apps |
| Local-only | No server component. Data lives entirely on device. | None | Low (no sync) | Local note apps, single-player games, calculators |
| Local-first | Local-only experience with optional peer or cloud sync. User owns the data. | Optional, for collaboration | Highest | Automerge-based apps, Obsidian with sync, Linear's local model |
Most teams think they're building "offline-tolerant" but their users need "offline-first." The gap between those two is enormous — it's the difference between showing a spinner with "waiting for connection" and letting the user do their entire job on an airplane.
Local-first means the device has a complete, usable copy of the data the user needs. Not a cache — a replica. The distinction matters:
Design consequences of treating the device as a replica:
| Technology | Platform | Max storage | Strengths | Weaknesses |
|---|---|---|---|---|
| SQLite | iOS, Android, Desktop, WASM | Device storage | Full SQL, ACID transactions, mature tooling, single-file database | No built-in sync, schema migrations need care |
| IndexedDB | Web browsers | Varies (typically 50%+ of disk) | Async, transactional, structured data, available in service workers | Terrible API ergonomics (use a wrapper like Dexie.js), no SQL, browser eviction policies |
| Realm | iOS, Android, Web (partial) | Device storage | Object-oriented, live objects, built-in sync (MongoDB Atlas), reactive | Vendor lock-in to MongoDB ecosystem, schema constraints |
| Core Data | iOS, macOS | Device storage | Deep OS integration, CloudKit sync built-in | Apple-only, complex concurrency model, opaque conflict resolution |
| OPFS (Origin Private File System) | Web browsers | Varies | Fast synchronous file access in workers, good for WASM-based SQLite | Limited browser support, no structured query without SQLite on top |
…
Catalog of reusable architectural primitives — boundaries, contracts, state machines, queues, caches, consistency models, and more. For each: what it is, when it's right, when it's WRONG. Use when selecting patterns for a design or evaluating whether a pattern fits.
Domain-Driven Design as a lens for system architecture — bounded contexts, aggregates, ubiquitous language, context mapping, domain events, and strategic vs tactical patterns. Use when modeling complex business domains, defining service boundaries, or evaluating whether a system's structure reflects its domain.
The Unix/Linux design philosophy as a lens for system design — mechanism vs policy, composability, small tools, text streams, convention over configuration, and the principle of least surprise. Use when evaluating designs for composability, simplicity, or separation of concerns.
Object-oriented design principles as a lens for system architecture — SOLID, composition over inheritance, the actor model, design patterns (and when they're wrong), encapsulation, polymorphism, and responsibility-driven design. Use when evaluating code organization, module boundaries, or object/component relationships.
Domain patterns for Azure cloud architecture — compute selection, managed services, identity (Entra ID), networking, data platform, messaging, deployment, cost management, and operational patterns. Use when designing or evaluating a system deployed on Microsoft Azure.
Adversarial review of a system design from 6 critical perspectives -- SRE, security, staff engineer, finance, operator, and developer advocate. Produces a unified risk assessment. Use for INTERACTIVE on-demand reviews during a design conversation (/adversarial-review). For RECIPE-DRIVEN reviews (where prior step context is needed), use the systems-design-critic agent instead.