Break your .NET microservices on purpose, so production does not have to.

---

Overview

Rupture is a chaos engineering tool for local .NET microservice systems. It injects controlled failures, collects request observations, validates business invariants, and generates a technical Markdown report that explains whether the system recovered safely.

$ rupture run payment-timeout

  Scenario: payment-timeout

  Injecting 8s latency into Payments.Api...
  Sending checkout request...
  Collecting telemetry...
  Validating business invariants...
  Generating report...

  Result: Failed

  The system recovered technically, but violated a business invariant
  or latency objective.

---

What it does

• Runs chaos scenarios defined in YAML
• Injects latency, HTTP 500, timeout, and duplicate event faults
• Targets ASP.NET Core Minimal API services via internal X-Rupture-* headers
• Validates HTTP expectations and SQL business invariants
• Generates a Markdown report with impact, recommendations, and a resilience score (0–100)
• Ships with a realistic ecommerce sample: Gateway, Orders, Inventory, Payments, and Notifications

---

Stack

Layer	Technology
Runtime	.NET 10, C#
APIs	ASP.NET Core Minimal APIs
Orchestration	Aspire AppHost
Infrastructure	PostgreSQL, Redis, RabbitMQ
Observability	OpenTelemetry
Resilience	Microsoft.Extensions.Http.Resilience, Polly
Testing	xUnit, Testcontainers
CLI	System.CommandLine, Spectre.Console
Containers	Docker
Scenarios	YAML

---

Repository layout

Rupture/
├── src/
│   ├── Rupture.Cli/
│   ├── Rupture.Core/
│   ├── Rupture.AspNetCore/
│   ├── Rupture.Scenarios/
│   ├── Rupture.Reporter/
│   └── Rupture.Testing/
├── samples/Ecommerce/
├── scenarios/
├── tests/
└── docs/

---

Quick start

Prerequisites: .NET 10 SDK and Docker.

dotnet restore Rupture.slnx
dotnet build Rupture.slnx
dotnet test Rupture.slnx

Run a deterministic demo without starting any services:

dotnet run --project src/Rupture.Cli -- run payment-timeout --dry-run
dotnet run --project src/Rupture.Cli -- report

---

Run against the ecommerce sample

1. Start local infrastructure

docker compose up -d

2. Start services

dotnet run --project samples/Ecommerce/Orders.Api
dotnet run --project samples/Ecommerce/Inventory.Api
dotnet run --project samples/Ecommerce/Payments.Api
dotnet run --project samples/Ecommerce/Gateway.Api

3. Run the scenario

dotnet run --project src/Rupture.Cli -- run payment-timeout \
  --base-url http://localhost:8080 \
  --connection-string "Host=localhost;Port=5432;Database=ecommerce;Username=postgres;Password=postgres"

4. Print the latest report

dotnet run --project src/Rupture.Cli -- report

---

CLI reference

rupture run <scenario>    # Run a chaos scenario
rupture report            # Print the latest report

Option	Description
--scenarios-dir	Path to scenarios directory (default: scenarios)
--output	Path to reports output directory (default: reports)
--base-url	Base URL of the gateway service
--checkout-path	Checkout endpoint path (default: /checkout)
--connection-string	PostgreSQL connection string for invariant validation
--dry-run	Simulate the scenario without starting services
--verbose	Show detailed output

---

ASP.NET Core integration

builder.Services.AddRupture(options => options.ServiceName = "Payments.Api");

app.UseRupture();

Faults are activated via internal headers — safe for use only within your local network:

X-Rupture-Scenario: payment-timeout
X-Rupture-Service: Payments.Api
X-Rupture-Fault: latency
X-Rupture-Duration: 8000

---

Scenario format

name: payment-timeout
description: Simulates a slow payment provider

target:
  service: Payments.Api
  endpoint: POST /payments

faults:
  - type: latency
    duration: 8s
    probability: 100

expectations:
  - name: gateway_should_not_timeout
    type: http_response_time
    maxDuration: 3s

  - name: paid_orders_must_have_reserved_stock
    type: business_invariant
    query: |
      SELECT COUNT(*)
      FROM orders o
      LEFT JOIN inventory_reservations r ON r.order_id = o.order_id
      WHERE o.status = 'Paid'
      AND r.order_id IS NULL
    expected: 0

---

Report output

Each run writes a Markdown report to reports/ containing:

• Scenario name and affected services
• Injected faults and requests executed
• Trace hints and business rules validated
• Result, impact summary, and technical recommendations
• Resilience score from 0 to 100

---

Roadmap

• Persist run history
• Add richer OpenTelemetry trace correlation
• Add first-class broker fault injection
• Add Kubernetes and Docker network chaos adapters
• Publish Rupture.Cli as a .NET global tool and Rupture.AspNetCore as a NuGet package

---

License

MIT © Rupture contributors