vogels_skill
- Python
3
GitHub Stars
3
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill copyleftdev/sk1llz --skill vogels- philosophy.md5.2 KB
- references.md4.5 KB
- SKILL.md13.1 KB
Overview
This skill encodes Werner Vogels' cloud-architecture principles to help you design resilient, highly available systems. It emphasizes failure-first design, eventual consistency, API-first thinking, and practical patterns for operating at AWS scale. Use the patterns and guidance to build services that tolerate faults and recover automatically.
How this skill works
The skill inspects architectural choices and recommends concrete patterns: circuit breakers, retries with jitter, cell-based partitioning, and eventual-consistency handlers with versioning. It analyzes trade-offs (availability vs. consistency), suggests per-operation consistency models, and provides runnable Python patterns for operational concerns. It also highlights deployment, observability, and testing practices to reduce blast radius and automate recovery.
When to use it
- Designing microservices expected to operate across multiple availability zones or regions
- Building systems that must remain available under network partitions or degraded dependencies
- Defining APIs that will be long-lived and require careful versioning and backward compatibility
- Implementing distributed data stores or caches where eventual consistency is acceptable
- Automating deployments, rollbacks, and operational runbooks for production services
Best practices
- Assume components fail; design for isolation, retries, and graceful degradation
- Prefer asynchronous communication and idempotent operations when possible
- Use timeouts, circuit breakers, and backoff with jitter to prevent cascades
- Partition traffic into independent cells to limit blast radius and enable incremental scaling
- Build observability and chaos tests early; measure p50/p99/p999 and customer impact
Example use cases
- High-traffic e-commerce checkout where inventory updates choose CP for payments and AP for carts
- Global user profile service using cell-based routing and eventual consistency for non-critical fields
- A public API that must remain stable: versioned endpoints, graceful deprecation, and compatibility guards
- A distributed cache with hinted handoff and anti-entropy to repair partitions without downtime
- Operational tooling that automates deploys, rollbacks, and health-driven failovers
FAQ
Choose eventual consistency when lower latency and higher availability matter and temporary divergence has low customer impact; pick strong consistency only for operations where correctness is critical (payments, inventory reservations).
How many availability zones or cells should I use?
Start with at least two AZs for redundancy; aim for three+ cells or zones for fault isolation and smoother failovers as traffic and risk tolerance grow.