Rebooting Microreboot: Architectural Support for Safe, Parallel Recovery in Microservice Systems
Organizations: Max Planck Institute for Software Systems (MPI-SWS), Saarbrücken, Germany
Abstract
Microreboot enables fast recovery by restarting only the failing component, but in modern microservices naive restarts are unsafe: dense dependencies mean rebooting one service can disrupt many callers. Autonomous remediation agents compound this by actuating raw infrastructure commands without safety guarantees. We make microreboot practical by separating planning from actuation: a three-agent architecture (diagnosis, planning, verification) proposes typed remediation plans over a seven-action ISA with explicit side-effect semantics, and a small microkernel validates and executes each plan transactionally. Agents are explicitly untrusted; safety derives from the ISA and microkernel. To determine where restart is safe, we infer recovery boundaries online from distributed traces, computing minimal restart groups and ordering constraints. On industrial traces (Alibaba, Meta) and DeathStarBench with fault injection, recovery-group inference runs in 21 ms at P99; typed actuation reduces agent-caused harm by 95% in simulation and achieves 0% harm online. The primary value is safety, not speed: LLM inference overhead increases TTR for services with fast auto-restart.
Figures & tables
| Action | Effect Type | Inverse/Comp. | Example Scenario |
|---|---|---|---|
| Restart | Restartable | Re-execute | Restart pod/service for transient failures |
| Drain | Compensatable | RestoreTraffic | Shield hub before disruptive changes |
| RestoreTraffic | Reversible | Drain | Resume traffic after planned drain |
| CircuitBreak | Reversible | Reset to default | Isolate unstable dependency |
| RateLimit | Reversible | Remove limit | Protect upstream from retry storms |
| Scale | Reversible | Scale by | Adjust capacity under resource stress |
| RQ | Experiment | Incidents |
| RQ2 | Social Network harm validation (3 configs) | 110 |
| RQ2 | Hotel Reservation harm validation | 10 |
| RQ3 | TTR comparison vs Kubernetes auto-restart | 15 |
| RQ3 | Multi-service parallel (5 services/incident) | 3 |
| RQ3 | Reproducibility (3 seeds 30) | 90 |
| RQ4 | Fault diversity (5 types 20) | 100 |
| Simulation | Social Network | Hotel Res. | |
|---|---|---|---|
| Configuration | (N=100) | (online) | (online) |
| Raw-Tools | 77% | 90% [74, 98] N=30 | — |
| ISA-Only | 24% ( 69%) | 0% [0, 12] N=30 | — |
| ISA+Critic | 4% ( 95%) | 0% [0, 7] N=50 | 0% [0, 31] N=10 |
| Approach | Flexibility | Safety Mechanism | Rollback |
|---|---|---|---|
| Raw tools ( kubectl , APIs) | High | None | Manual |
| Policy verification | High | Post-hoc validation | Tool-specific |
| Undo mechanisms | High | State snapshots | Automatic |
| Typed ISA (ours) | Constrained | Effect-type enforcement | Transactional |
Microservice Architecture
Microservice architecture organizes applications as independently deployable services and studies their design, operation, reliability, and coordination.
See all 19 papers