Infrastrukturkapazität und Kosten

Erklärt Infrastrukturengpässe und Skalierungskosten anhand tatsächlicher Verbindungs-, Speicher- und CPU-Grenzen statt Serveranzahl allein.

capacity-infrastructure-costs

Teammitglieder mit diesem Skill

AgentOtto

Entdecke, wie der Skill hilft

Wann ist der Skill hilfreich?

Nutze dies, wenn zusätzliche Server Kosten erhöhen, aber Latenz und Ausfälle bestehen bleiben.

Wobei hilft er dir?

Ermittelt Datenbank-Verbindungsgrenzen, Speicherdruck und CPU-Drosselung.
Setzt Instanzzahlen und Poolgrößen zur Kapazität nachgelagerter Dienste in Beziehung.
Schlägt Skalierungsgrenzen und Kostenkontrollen anhand des gemessenen Engpasses vor.

Das könntest du fragen

Erkläre erschöpfte Datenbankverbindungen nach verdoppelter Containerzahl und schlage eine begrenzte Kapazitätskonfiguration vor. Berechne den Verbindungsbedarf aller Replikate und Worker. Lege eine geprüfte Poolgrenze fest und zeige die verbleibende Datenbankreserve.

Ausführliche Dokumentation

Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.

Details…Weniger anzeigen

Capacity & Infrastructure Costs

Right-size infrastructure from measured workload characteristics rather than guesswork, and guard every auto-scaling or pay-per-use resource with hard upper ceilings so a traffic spike, retry loop, or runaway job cannot cause an outage or a billing shock.

Bottleneck Diagnosis (The USE Method)

Before scaling up hardware or adding replicas, check Utilization, Saturation, and Errors for every resource along the request path:

Database & Connection Pools (Most Common Real Bottleneck):
- Adding 20 application containers that each open a 20-connection pool (400 connections) will overwhelm a database configured for max_connections = 100.
- Size per-instance pool limits so $\text{max_instances} \times \text{pool_size} + \text{admin_reserve} < \text{DB max_connections}$, or place a connection pooler (PgBouncer / RDS Proxy / Supavisor) in front of the database.
Memory Working Set vs. Limits (OOMKills):
- Monitor container memory working set (container_memory_working_set_bytes) and language runtime heap limits (e.g., Node --max-old-space-size set to ~75–80% of container memory limit so GC runs before the Linux kernel OOM-killer terminates the process with exit code 137).
CPU Throttling vs. Average CPU:
- Check container CFS throttling (container_cpu_cfs_throttled_periods_total) and event-loop lag alongside average CPU utilization; bursty workloads can experience severe tail-latency spikes even at 40% average CPU if limits are overly tight.

Safe Autoscaling & Cost Guardrails

Cost / Capacity Risk	Mitigation to Enforce
Unbounded Horizontal Autoscaling	Always set a hard `maxReplicas` / `max_instances` cap paired with edge rate-limiting and queue backpressure so a DDoS or retry storm cannot spin up hundreds of instances.
Network Egress & NAT Gateway Multipliers	Serve static assets, media, and large downloads through a CDN with proper `Cache-Control` headers (`immutable` for fingerprinted assets); use VPC endpoints / private networking for high-volume internal storage/DB traffic.
Log, Trace & Metric Cardinality Explosion	Never put unbounded user IDs, URLs with query strings, or UUIDs into metric labels (Prometheus/Datadog tag cardinality explosion). Sample high-volume debug/info traces and set retention TTLs on log buckets.
Orphaned Storage & Preview Environments	Automate teardown of ephemeral PR preview environments, unattached block volumes, old container registry tags, and expired build artifacts via lifecycle rules.

When proposing an infrastructure or scaling change, state the expected capacity headroom, failure mode at ceiling, and estimated monthly cost delta explicitly.

Enthaltene Dateien 1

SKILL.md