What this prompt does
This prompt makes the AI a distributed systems architect designing a cloud file storage system similar to [reference_platform] for [user_count] users with [storage_per_user] each. It works through storage architecture, a metadata service, the sync protocol, conflict resolution, and a sharing and collaboration layer. Files are split into [chunk_size] chunks stored in [object_storage] with [replication_factor] replication, and content-addressable hashing enables chunk-level deduplication across all users.
The structure works because file sync breaks in predictable places: chunking, deduplication, and conflict handling. Forcing the deduplication math up front matters because the expected savings change the storage backend decision more than people expect, and chunk-level hashing means identical content stored by different users only costs space once. The sync protocol uses per-device cursors so each device pulls only changes since its last sync rather than re-downloading the tree, and offline edits queue locally and replay on reconnect. Conflict resolution compares parent version IDs — attempting operational-transform merges for documents and saving clearly named conflict copies for binaries via [conflict_ui] so nothing is silently lost.
When to use it
- You're designing a sync or storage layer and want chunking and dedup decided early
- You need a metadata model that tracks the file tree, permissions, and per-device sync state
- You want a sync protocol that handles offline edits and replays on reconnect
- You're tackling conflict resolution for simultaneous offline edits
- You need sharing with nested-folder permission inheritance and link expiration
- You're adding real-time collaboration with multiple simultaneous editors
- You want a deduplication and durability estimate at
[user_count]scale before choosing a backend
Example output
Expect a layered design: a storage section with [chunk_size] chunking, content-addressable dedup via SHA-256, [replication_factor] replication across availability zones, and a savings estimate; a metadata schema in [metadata_database] covering the file tree, sharing relationships, version chains, and per-device sync cursors; the client-server sync protocol with cursor-based change pulls and offline replay; a conflict-resolution flow distinguishing document merges from binary conflict copies; and a sharing layer with link permissions, expiration dates, nested inheritance, and a CRDT or OT engine for up to [max_collaborators] simultaneous editors. It's an architecture walkthrough, not code.
Pro tips
- Run the deduplication math early; the realistic dedup ratio at
[user_count]scale can reshape your[object_storage]choice - Pick
[chunk_size]to balance dedup granularity against metadata overhead — smaller chunks dedup better but multiply bookkeeping - Lean on per-device sync cursors so devices pull deltas, not full trees, on every change
- Distinguish document and binary conflict handling clearly; OT merges suit text, conflict copies suit binaries
- Set
[replication_factor]to meet your durability goal across availability zones, not just within one - Design nested-permission inheritance carefully; ambiguous inheritance rules are a common source of sharing bugs
