What this project demonstrates

Resilience Gate connects a small URL-shortening application to a release process that asks a harder question than whether its pods are running: can this exact candidate keep a defined contract when a dependency fails, recover within the observation window, and leave the experiment clean? The answer depends on recorded observations tied to the candidate, rather than a reassuring dashboard or a successful build alone.

The application is intentionally understandable. A client creates a short URL, PostgreSQL keeps the durable mapping, and Redis accelerates redirects. In payment-enabled environments, creation also requires an x402 authorization, a separate Permit2 signer, and facilitator settlement. That small request path gives the platform three distinct failure boundaries to exercise: essential storage, an optional acceleration layer, and a service used by the paid traffic client.

The release decision is a chain of responsibilities

An image is published and signed in CI. Kargo discovers candidate artifacts and renders the selected image digest with environment configuration into Git. Argo CD reconciles those manifests into Kubernetes. Staging verification then runs bounded dependency failures under load, records measurements, checks recovery, and checks cleanup.

These responsibilities answer different questions. Publication creates an artifact. A digest identifies its bytes. Reconciliation brings an environment toward the desired manifests. Verification tests a bounded behavior of the deployed candidate. A passing staging verification makes that Freight eligible for normal downstream selection; an operator still chooses the production-like promotion. Development is configured for automatic promotion, while staging and prod retain manual transitions. The promotion contract records the exact policy.

The project uses prod to mean a production-like environment on an owned testnet. Development, staging, and production-like workloads occupy namespaces in the same lab cluster. Namespace scoping and explicit target selection limit the experiments, but they do not supply separate-cluster isolation or public-production assurance.

Read an observation as a bounded answer

The evidence separates implementation, tests, and live records. Source explains what the system is designed to do. Credential-free tests exercise deterministic boundaries. A retained scorecard explains which observations passed for one candidate and one time window. A screenshot illustrates visible state and needs its provenance before it supports a release claim.

For example, a Redis miss counter increase is useful evidence that database fallback was exercised. It does not establish that Redis failed: ordinary cold-cache reads increment the same counter. A meaningful Redis case combines that signal with a target outage, useful traffic, bounded redirect latency, application stability, and recovery. The Redis walkthrough follows the complete argument.

Likewise, the paid sequence 402 → signed 201 → redirect 302 → replay 409 establishes a bounded HTTP and application replay observation. It does not establish audited custody, settlement finality, or success of every later payment. The paid request walkthrough explains where settlement and database persistence can diverge.

What the site helps you inspect

Start with the system tour to connect the request path to the delivery path. Then follow a reading path according to whether you are reviewing the design, learning the mechanisms, or operating the local environment. The glossary defines terms at the events where they matter.

The release question has a deliberately limited answer. The repository demonstrates digest-bound delivery, selected sequential pod-failure scenarios, and scoped recovery observations. It does not demonstrate every dependency combination, a long-duration outage, backups, disaster recovery, or a highly available payment platform. The known limitations remain part of the design, because an honest limit helps a reviewer decide what further evidence would be needed.

Locate the implementation

• Application routes and dependency boundaries implement creation, redirect, liveness, readiness, and counters.
• Payment adapter owns header decoding and facilitator calls; signer service owns payer keys and local signing.
• Kargo resources and Argo CD resources establish promotion and reconciliation ownership.
• Gate orchestration and scoring decide what a bounded run must observe.
• Public evidence index and verification report distinguish inspectable historical artifacts from the later release snapshot.