Sharing & Isolation Semantics

Envy operates on the principle of Request-Routing Isolation. It isolates the code execution of modified microservices while purposefully sharing underlying cluster resources and dependencies from the deployed reference baseline.

---

What is Isolated?

When a composition is active, Envy separates the following resources and request paths:

1. Workload Execution

• HTTP overrides run as dedicated Kubernetes Deployments; finite and scheduled overrides run as owned Job and CronJob resources inside an isolated, temporary namespace named envy-cmp-<id>.
• Overridden pods have independent resource allocations, environment configurations, and container images.
• An override crash does not replace or restart baseline pods. Shared dependencies can still be affected by preview load or writes.

2. Ingress & Traffic Routing

• HTTP compositions receive a dedicated, deterministic preview URL: http://cmp-<id>.envy.localhost:8080
• Normal traffic hitting http://baseline.envy.localhost:8080 will never reach an override pod.
• Mesh routes match the composition value in W3C baggage. This header is routing context, not authentication: callers inside the mesh may also supply it. Configure access controls separately.
• Endpoint-free Job compositions have no ingress route or public endpoint.

3. Lifecycle & Expiry

• Compositions have an explicit TTL (defaulting to 8 hours). When expired, their namespaces, routes, and workloads are automatically destroyed without touching baseline pods.

---

What is Shared?

Because Envy is designed for rapid integration testing rather than multi-tenant sandboxing, the following layers are shared:

1. Unmodified Workloads

Any microservice not explicitly listed in the composition’s overrides map continues to run from the baseline namespace (envy-baseline).

2. State & Persistence (Databases & Caches)

• Overridden services connect to the same shared baseline databases (e.g., PostgreSQL, MySQL, Redis) as the reference environment.
• Important: Any database writes or row mutations made during preview testing will mutate shared baseline data.
• If your test scenario involves destructive database schema drops or data purges, use a separate disposable database. Test tenant IDs help separate test records but do not isolate schema changes.

3. Asynchronous Side Effects & Message Queues

By default, preview messages use shared messaging infrastructure. Baseline consumers can process those messages unless the application and broker provide isolation.

Envy supports opt-in Google Pub/Sub isolation: prepared baseline subscriptions exclude preview messages, and Envy creates filtered subscriptions for each preview. This requires application context propagation, approved topic/consumer registration, and controller credentials. A worker is optional, so you can capture messages before deploying a consumer. Topics, databases, credentials, and external effects remain shared. This feature does not provide Kafka or SQS isolation.

---

Architectural Comparison

One application, two request paths

Both URLs reuse gateway and service-a. The selected mesh selects service-b v2 only when the request carries the matching composition ID. Both service-b versions connect to the same shared data.

Envy / routingPreview overrideShared baseline

Scroll sideways to follow wider branches, or read the connections below.

Read the connections

• Baseline URL → gateway · v1: baseline request.
• Preview URL → gateway · v1: preview request.
• gateway · v1 → service-a · v1: forward baggage.
• service-a · v1 → service-b · v1: no matching context.
• service-a · v1 → service-b · v2: composition=cmp-123.
• service-b · v1 → Database & cache: read / write.
• service-b · v2 → Database & cache: read / write.

---

Best Practices for Safe Sharing

1. Use Synthetic Test Entities: When running automated QA or agent browser tests, prefix test accounts, emails, and entities with test-envy-<id>.
2. Backward-Compatible Schemas: When migrating databases, apply additive changes (e.g., adding nullable columns) so shared baseline services are not broken.
3. Short Expiry Windows: Keep composition TTLs short (e.g., 2h or 4h) during active pull request review, allowing Envy’s garbage collection to reclaim resources after expiry. Cleanup requires a running reconciler and available infrastructure APIs.