Mountain + Exit
Exit is crossing from inside to outside. What entered must eventually exit—users log out, processes terminate, connections close. The exit point determines how cleanly departure happens. Proper exit releases resources, finalizes state, and notifies dependencies. Improper exit leaves resources locked, state inconsistent, and dependencies confused. Emergency exits bypass normal procedures for speed—kill processes, force disconnect, abandon transactions. The emergency path trades cleanup for immediate escape. Exit strategies matter as much as entry strategies. Systems easy to enter but difficult to exit trap users in vendor lock-in or broken workflows. Design exit paths as carefully as entry paths. The ability to leave cleanly is freedom.
Graceful exit follows proper procedures. Complete pending work, save state, release resources, notify dependencies. The orderly departure leaves system clean.
Emergency exit prioritizes speed over cleanup. Process kill terminates immediately. Connection drop abandons mid-transfer data. Transaction abort discards uncommitted changes. The rapid exit accepts collateral damage for immediate escape.
The exit type should match urgency. Normal shutdown uses graceful exit. System failure requires emergency exit. Intermediate scenarios balance cleanup thoroughness against exit speed.
Does exit require permission? Some systems allow free exit. Others restrict exit to prevent data loss or ensure cleanup.
Transaction systems may block exit during uncommitted transactions. "Unsaved changes will be lost" dialogs request exit confirmation. The restrictions prevent accidental exits that lose work.
But exit restrictions can trap users. Cannot exit until completing required steps. Cannot close until errors are fixed. Overly restrictive exit creates frustration. The restrictions should prevent genuine accidents without creating prison.
Departures sometimes involve exit interviews—formal processes gathering feedback and finalizing separation. The interview serves multiple purposes: understand why exit happened, ensure clean handoff, collect departing knowledge.
User account deletion might request exit reason. Service cancellation might offer retention discount. The exit interaction provides last opportunity to prevent departure or learn from it.
Exit interview design affects data quality. Mandatory long forms discourage exit completion. Optional brief surveys collect better data. The interview should be short enough to complete but substantive enough to be useful.
Is exit public or private? Does departure notify others or happen silently? The visibility affects both exiting entity and remaining system.
Logout events might notify connected users. Process termination might notify monitoring systems. The notification enables coordinated response to departure.
Silent exit creates detection problems. How long until absence is noticed? Who monitors for unexpected exits? The detection delay determines how quickly system adapts to departure.
Systems with many exit points create confusion. Users don't know which exit to use. Each exit might behave differently. The multiplicity creates inconsistency.
Consolidating exit points improves clarity. Single logout button is obvious. Multiple confusing exit options are problematic. But consolidation might be difficult when exits serve different purposes.
Exit point design should distinguish intentional multiplicity (different exits for different purposes) from accidental multiplicity (redundant exits doing same thing differently). Eliminate redundancy; preserve purposeful variety.
During mass exits, queues form. Concert ends, everyone exits simultaneously. System shutdown, all connections close together. The exit surge creates congestion.
Load balancers face exit queues during rolling deploys. Existing connections must drain before instance shutdown. Queue formation is temporary but must be managed.
Exit queue management prevents bottlenecks. Stagger exits to distribute load. Expand exit capacity temporarily during surge. Fast-track simple exits; route complex exits to thorough processing.
Trapped systems lack exit capability. Once entered, cannot leave. The entrapment might be unintentional (no exit designed) or deliberate (vendor lock-in).
Designing exit capability requires planning for data export, service migration, and dependency unwinding. The export should be complete and usable. Migration should be feasible without starting from scratch.
Lack of exit is ethical problem. Users should be able to leave with their data. The exit capability demonstrates respect for user agency. Intentionally preventing exit is hostile design.
Some exits pass irreversible thresholds. Account deletion cannot be undone. Data purging cannot be reversed. The permanent exit requires strong confirmation.
Confirmation patterns protect against accidental permanent exits. "Type 'DELETE' to confirm" requires deliberate action. Cool-down periods delay execution to enable reconsideration. The protections reduce regretted exits.
But excessive protection creates friction. Ten confirmation clicks to exit is hostile. Single confirmation for low-stakes exit is sufficient. The protection level should match exit reversibility.
Exits leave traces. Logout logs, deletion records, unsubscribe confirmations. The traces document that exit occurred and when. The documentation serves audit and recovery purposes.
Soft deletes leave exit traces while removing visibility. Account marked deleted but data preserved. The trace enables recovery from accidental exits.
Hard deletes remove traces completely. No recovery possible. The permanent erasure satisfies privacy requirements but prevents undo. The deletion policy should match regulatory and recovery requirements.
Systems can force exit involuntarily. Session timeout forces logout. Instance termination forces connection close. The forced exit happens regardless of readiness.
Forced exit needs warning when possible. "Session expires in 5 minutes" enables saving work. Countdown before instance termination enables graceful shutdown. The warning converts surprise forced exit into prepared exit.
Immediate forced exit without warning is appropriate for security events. Compromised session should terminate immediately. The security requirement overrides graceful exit courtesy.
Having exit strategy before entering enables confident entry. Knowing you can leave makes commitment safer. Dating, jobs, vendor selection—all benefit from exit planning.
Technical decisions should include exit strategy. How will we migrate off this platform if needed? What's our plan if this vendor disappears? The exit planning reduces lock-in risk.
Exit strategy doesn't mean expecting to exit. It means being prepared if exit becomes necessary. The preparation provides option value and negotiating power.