Live TodoMVC

Architecture decision 03 · Remote storage

Put the mailbox where responsibility belongs.

The mailbox does not need plaintext or merge logic, but it still owns a consequential job: admit requests, retain objects, expose metadata, enforce quotas, and return honest copies. Choose placement by that operational boundary.

Decision
Assign remote deployment risk, cost, and recovery obligations.
Core boundary
Encryption protects payload content; storage policy and backup protect access and availability.
Completion
Select a mailbox mode and assign every operational duty.

Placement chooser

There is no operationally neutral remote.

All adapters carry the same protocol role, but they distribute identity, credentials, quotas, recovery, and support differently. Choose by who should operate availability and where the user expects custody.

Cloudflare

Product-operated mailbox

Use the bundled Worker when the product should run one endpoint and control its admission, D1 metadata, and file-body storage.

  • Explicit access middleware and namespace policy
  • Configurable D1 and R2/S3 limits
  • Deployment owner operates backup and maintenance

Drive or WebDAV

User- or organization-owned storage

Use an existing account, NAS, or compatible server when storage custody should remain with its owner.

  • Provider credentials remain a product concern
  • Provider quotas and history govern availability
  • Recovery does not restore the provider login

Custom

Existing storage environment

Implement the adapter contract when another object or file system should own the mailbox role.

  • Preserve exact paths and list behavior
  • Define consistency, timeout, and auth semantics
  • Pass the shared adapter contract

Responsibility ledger

Assign what encryption cannot do.

A remote without plaintext can still identify activity, deny service, return old state, or lose the only stored copy. The deployment must make each remaining responsibility explicit.

Access

Who may call it?

Authentication and authorization control read, write, delete, list, recovery, and maintenance operations.

Metadata

What remains visible?

Paths, sizes, timing, request identity, mesh addresses, and device identifiers may remain observable.

Availability

What survives failure?

Retention, version history, backup, and restore protect against loss, deletion, withholding, and rollback.

Operations

Who keeps it healthy?

Quotas, capacity, compaction policy, alerts, credential rotation, and incident response need owners.

Backup boundary

The mailbox is not automatically a backup.

If the provider loses or deletes every copy, Interocitor cannot recreate the missing artifacts. Important deployments need provider history or an independent copy and a restoration path that has actually been exercised.

Before deployment

Make the operational contract testable.

The owner should be able to answer these questions without depending on library internals.

  • Name who provisions mailbox locations and who may create new namespaces.
  • List which request and storage metadata the provider and product can observe.
  • Set row-change, snapshot, and durable-file body limits from measured workloads.
  • Choose who may compact and how stale or poisoned state is surfaced.
  • Define retention, version history, independent copy, and restore testing.
  • Record the response to credential exposure, quota exhaustion, rollback, and provider loss.

Canonical detail

Operate the selected backend.

Continue with the adapter or deployment owner for exact configuration, security policy, and maintenance procedures.