domain-cloud-native
actionbook/rust-skills
Build cloud-native Rust apps with stateless design, graceful shutdown, and observability patterns.
What is domain-cloud-native?
This skill provides domain constraints and design patterns for building cloud-native applications in Rust. Use it when architecting microservices, containerized workloads, or Kubernetes-deployed systems that require stateless design, graceful shutdown, distributed tracing, and health checks.
- Enforce stateless design to support pod rescheduling and horizontal scaling
- Implement graceful shutdown with SIGTERM handling for zero-downtime deployments
- Add distributed tracing and observability with tracing and OpenTelemetry
- Provide health check endpoints (liveness and readiness) for orchestration
- Apply 12-factor app principles with environment-based configuration
- Optimize for container deployment with small binary sizes
How to install domain-cloud-native
npx skills add https://github.com/actionbook/rust-skills --skill domain-cloud-nativeHow to use domain-cloud-native
- 1.Review the domain constraints table to understand 12-factor, observability, health checks, and graceful shutdown requirements
- 2.Implement graceful shutdown using tokio::signal and connection draining
- 3.Add health and readiness endpoints as dedicated HTTP routes
- 4.Configure the application via environment variables following 12-factor principles
- 5.Integrate tracing spans and OpenTelemetry for distributed tracing
- 6.Ensure all state is external (Redis, database) rather than local to the process
Use cases
- Building microservices that run in Kubernetes clusters
- Implementing gRPC services with service mesh integration
- Adding observability to distributed systems for debugging
- Creating health check endpoints for container orchestrators
- Designing stateless APIs that scale horizontally
- Backend engineers building cloud-native systems
- DevOps engineers designing containerized Rust applications
- Microservices architects
- Platform engineers implementing Kubernetes operators
domain-cloud-native FAQ
Pods can be killed or rescheduled at any time by the orchestrator. Local persistent state would be lost, so all state must be stored externally in databases or caches.
Use tonic for gRPC services, kube and kube-runtime for Kubernetes client and operators, and tracing with opentelemetry for observability.
Use tokio::signal to listen for SIGTERM, then drain existing connections before terminating. The skill provides a code pattern using axum's with_graceful_shutdown.
Liveness checks (/health) indicate the process is running; readiness checks (/ready) verify dependencies like databases are accessible and the service can handle traffic.
Use the tracing crate to create spans around requests and operations, then export them via OpenTelemetry to a collector for debugging distributed systems.
Full instructions (SKILL.md)
Source of truth, from actionbook/rust-skills.
name: domain-cloud-native description: "Use when building cloud-native apps. Keywords: kubernetes, k8s, docker, container, grpc, tonic, microservice, service mesh, observability, tracing, metrics, health check, cloud, deployment, 云原生, 微服务, 容器" user-invocable: false
Cloud-Native Domain
Layer 3: Domain Constraints
Domain Constraints → Design Implications
| Domain Rule | Design Constraint | Rust Implication |
|---|---|---|
| 12-Factor | Config from env | Environment-based config |
| Observability | Metrics + traces | tracing + opentelemetry |
| Health checks | Liveness/readiness | Dedicated endpoints |
| Graceful shutdown | Clean termination | Signal handling |
| Horizontal scale | Stateless design | No local state |
| Container-friendly | Small binaries | Release optimization |
Critical Constraints
Stateless Design
RULE: No local persistent state
WHY: Pods can be killed/rescheduled anytime
RUST: External state (Redis, DB), no static mut
Graceful Shutdown
RULE: Handle SIGTERM, drain connections
WHY: Zero-downtime deployments
RUST: tokio::signal + graceful shutdown
Observability
RULE: Every request must be traceable
WHY: Debugging distributed systems
RUST: tracing spans, opentelemetry export
Trace Down ↓
From constraints to design (Layer 2):
"Need distributed tracing"
↓ m12-lifecycle: Span lifecycle
↓ tracing + opentelemetry
"Need graceful shutdown"
↓ m07-concurrency: Signal handling
↓ m12-lifecycle: Connection draining
"Need health checks"
↓ domain-web: HTTP endpoints
↓ m06-error-handling: Health status
Key Crates
| Purpose | Crate |
|---|---|
| gRPC | tonic |
| Kubernetes | kube, kube-runtime |
| Docker | bollard |
| Tracing | tracing, opentelemetry |
| Metrics | prometheus, metrics |
| Config | config, figment |
| Health | HTTP endpoints |
Design Patterns
| Pattern | Purpose | Implementation |
|---|---|---|
| gRPC services | Service mesh | tonic + tower |
| K8s operators | Custom resources | kube-runtime Controller |
| Observability | Debugging | tracing + OTEL |
| Health checks | Orchestration | /health, /ready |
| Config | 12-factor | Env vars + secrets |
Code Pattern: Graceful Shutdown
use tokio::signal;
async fn run_server() -> anyhow::Result<()> {
let app = Router::new()
.route("/health", get(health))
.route("/ready", get(ready));
let addr = SocketAddr::from(([0, 0, 0, 0], 8080));
axum::Server::bind(&addr)
.serve(app.into_make_service())
.with_graceful_shutdown(shutdown_signal())
.await?;
Ok(())
}
async fn shutdown_signal() {
signal::ctrl_c().await.expect("failed to listen for ctrl+c");
tracing::info!("shutdown signal received");
}
Health Check Pattern
async fn health() -> StatusCode {
StatusCode::OK
}
async fn ready(State(db): State<Arc<DbPool>>) -> StatusCode {
match db.ping().await {
Ok(_) => StatusCode::OK,
Err(_) => StatusCode::SERVICE_UNAVAILABLE,
}
}
Common Mistakes
| Mistake | Domain Violation | Fix |
|---|---|---|
| Local file state | Not stateless | External storage |
| No SIGTERM handling | Hard kills | Graceful shutdown |
| No tracing | Can't debug | tracing spans |
| Static config | Not 12-factor | Env vars |
Trace to Layer 1
| Constraint | Layer 2 Pattern | Layer 1 Implementation |
|---|---|---|
| Stateless | External state | Arc<Client> for external |
| Graceful shutdown | Signal handling | tokio::signal |
| Tracing | Span lifecycle | tracing + OTEL |
| Health checks | HTTP endpoints | Dedicated routes |
Related Skills
| When | See |
|---|---|
| Async patterns | m07-concurrency |
| HTTP endpoints | domain-web |
| Error handling | m13-domain-error |
| Resource lifecycle | m12-lifecycle |
Related skills
More from actionbook/rust-skills and the wider catalog.

domain-embedded
Embedded Rust development constraints: no_std, no heap, interrupt safety, and hardware ownership patterns.

domain-fintech
Fintech domain constraints and patterns for Rust: precision, immutability, and audit trails.

domain-iot
Design IoT apps with offline-first, power-efficient, and secure patterns in Rust.

domain-ml
Build ML/AI applications in Rust with efficient tensor operations, GPU acceleration, and model inference.

domain-web
Build concurrent, type-safe web services with async handlers, middleware, and shared state patterns.

m01-ownership
Diagnose and fix Rust ownership, borrowing, and lifetime errors by understanding data roles and scope boundaries.