The problem
Provisioning outlives a single HTTP request.
A wallet could not treat hosted-service setup as one synchronous request. Provisioning crossed an account service, witness infrastructure, and watcher infrastructure. Any step could time out after making a partial change, and the wallet still needed a trustworthy answer after it restarted.
What I owned
The parts I was responsible for.
I identified the missing backend boundary, called the initial design meeting, proposed the architecture, and implemented the onboarding path across the wallet and service repositories.
- Durable background operations for account and service creation and deletion.
- Persistent operation state that a wallet can recover after a restart.
- Wallet integration across Locksmith and FortWeb.
- Service integration across kf-boot, witness, and watcher infrastructure.
Engineering decisions
Persist the operation, not only the result
The backend records progress before it starts remote work. A client can reconnect and ask what happened instead of guessing from a dropped HTTP response.
Make retries safe
A timeout does not prove that the remote service did nothing. Idempotent operations let the wallet retry without allocating the same service twice.
Treat cleanup as part of the workflow
Cancellation and failure paths track what was created, then remove partial state when the operation cannot complete cleanly.
Validation
What the implementation had to prove.
- Account creation and hosted-service allocation through the local wallet stack.
- Retry, cancellation, timeout, and partial-failure behavior.
- Operation recovery after the initiating client disconnects.