Constraints are architectural inputs
A platform designed around uninterrupted broadband, abundant compute, and mature operations can fail before its product value is tested. Connectivity, device capability, power, cost, skills, and maintenance capacity belong in the first architecture conversation.
Connectivity
Intermittent
Storage
Bounded
Compute
Constrained
Offline-first is a data strategy
Offline-first behavior requires explicit local state, durable identifiers, synchronization policy, conflict handling, and understandable user feedback. A cached interface without a data-consistency model is not an offline architecture.
type SyncPolicy = {
localWrite: "durable";
conflict: "explicit";
retry: "bounded-backoff";
userState: "visible";
};Define budgets before features
| Budget | Question | Response |
|---|---|---|
| Bandwidth | What must cross the network? | Minimize and batch |
| Compute | What can run locally? | Bound work explicitly |
| Storage | What must persist? | Prioritize durable state |
| Operations | Who can recover failure? | Design observable recovery |
Degrade capability, not trust
Graceful degradation should make state visible: what is saved, what is pending, what requires connectivity, and what the system can guarantee. Silent partial failure is more damaging than an honest limitation.
Operational simplicity compounds
Smaller dependency surfaces, progressive delivery, useful logs, and recoverable state reduce the expertise required during failure. Architecture becomes sustainable when the operating model is part of the design.