Blue‑Green Strategy for Always‑On TCP Workloads on Azure Container Apps

Scenario: Always‑on workloads in Azure Container Apps continuously pull from a TCP source, process the stream, and push into Azure Managed Redis, which is then consumed by another always‑on Container Apps workload that writes to a database. 

Challenge: Standard revision traffic splitting isn’t a fit because there’s no HTTP ingress-based routing for this workload pattern as defined here; instead, the approach uses a flag‑controlled activation plus a temporary/mock Redis path to validate a new revision end‑to‑end before promotion.

Why this pattern is needed

Azure Container Apps supports revisions and traffic management primarily for HTTP ingress scenarios. But for always‑running TCP pipelines, there’s no meaningful way to “route 10% traffic” to a new revision. Instead, the safer approach is to deploy the new revision with mock/non‑prod dependency bindings, validate it end‑to‑end, and only then promote it using a flag‑controlled switch.

Why this pattern exists (and when it applies)

Azure Container Apps revisions work well for many HTTP scenarios, but some always‑on integration workloads are different:

• They run 24×7
• They pull data from a TCP source
• They have no HTTP endpoint that would support traffic percentage routing
• They must reduce the risk of downtime during deployment and help avoid duplicate processing

In these cases, you can still implement a practical blue‑green model by switching “what does work” (via flags/locks) and where processed data is written (prod vs temporary Redis), rather than trying to split HTTP traffic. This post walks through a pattern that uses a processing flag (e.g., PROCESSING_ENABLED=true|false) and a separate temp Redis for safe validation before promotion.

High-level idea: validate new revisions using “mock resource connections”

The key design choice is:
Deploy the new (green) revision with mock/non‑prod resource bindings first—specifically, a temporary Redis—and validate the complete pipeline end‑to‑end using live TCP input (or a controlled subset), while keeping production writes isolated.

• Production pipeline continues unchanged (Prod TCP → Prod Receiver/Processor → Prod Redis → Prod Consumer → DB).
• Validation pipeline (Green) runs in parallel but writes to Temp Redis, where the downstream consumer reads and (optionally) writes to a non‑prod database or a safe validation sink.

Promotion then becomes a controlled, auditable step: flipping the processing mode/flag so the new revision becomes production‑active, and cleaning up the old revision after confidence gates pass.

Architecture overview

Zonal architecture with production and validation paths

Figure 1

This diagram illustrates the runtime topology across availability zones and how the Receiver and Processor revisions are validated safely using a Temp Redis path.

1. Azure Region – Zonal Redundancy boundary
   The large outer frame shows the workload running with zonal redundancy. The goal is to keep the platform resilient while revisions are deployed into multiple availability zones and validated.
2. Receiver (ACA) – Production revision
   On the production side, the Receiver revision runs in RUN_MODE = Prod and participates in normal processing. It pulls frames from the Prod TCP Source.
3. Processor (ACA) – Production revision
   The Processor runs in RUN_MODE = Prod and continues the pipeline, using the production data path. 
4. Azure Managed Redis (Non‑Prod) container in the diagram includes two logical targets
   The diagram shows a Redis layer with two logical destinations:
   • Prod Redis (used by production path)
   • Temp Redis (used by validation path)
     This separation allows the new revision to be validated without mutating the production Redis state.
5. Receiver (ACA) – Green revision in mock mode
   The new Green revision of Receiver is deployed with RUN_MODE = Mock and configured to write outputs to Temp Redis instead of Prod Redis. This allows the Receiver to exercise the real TCP read/parsing logic while isolating outputs.
6. Processor (ACA) – Green revision in mock mode
   The new Green revision of Processor runs in RUN_MODE = Mock, reads from Temp Redis, and pushes results to the validation sink (for example a non‑prod database or a safe validation path). The key idea is validate the full flow without using production write targets.
7. Promotion principle (implicit in the design)
   After validation passes, promotion is performed by switching configuration, so the validated revision begins using Prod Redis and production write targets (and/or enabling processing via a flag), rather than relying on HTTP traffic splitting.

CI/CD workflow (deploy → mock validate → promote)

Figure 2

This figure shows the multi‑stage pipeline gates that ensure the green revision is validated before it becomes production‑active.

1. Build stage: “job: build image / tag with commit SHA”
   Pipeline builds the container image and tags it for traceability.
2. Pre‑deploy tests: unit + integration
   Fast tests run before deployment to reduce obvious regressions.
3. Deploy staging Green: Receiver + Processor revisions
   The pipeline deploys the Green revisions first, but sets them to RUN_MODE=Mock (or equivalent) and points them to Temp Redis. This is the core safety mechanism: deploy and validate without touching production state.
4. Enable mock path & run smoke tests
   Smoke tests validate:
   • Receiver can read TCP input correctly
   • Receiver writes expected outputs to Temp Redis
   • Processor reads from Temp Redis
   • Processor produces expected result artifacts (validation sink) 
5. Gate: “Locks acquired and processed successfully”
   Promotion occurs only after validation gates pass (lock acquisition + processing success conditions). This supports safer promotion for non‑HTTP pipelines.
6. Promote: switch to production‑active
   Promotion is performed using a controlled config flip (examples in your docs include flags like prod_active=true / PROCESSING_ENABLED=true), and switching dependency bindings from Temp Redis → Prod Redis. 
7. Cleanup: delete old revision / disable mock artifacts
   After post‑promotion monitoring stabilizes, the old revision can be cleaned up to keep the environment tidy.

The core mechanism: flags + locks (for background processing)

Because there is no HTTP traffic split, the “cutover” is achieved by controlling execution:

• Use a boolean (or enum) flag such as:
  • PROCESSING_ENABLED=true|false
  • prod_active=true|false
  • RUN_MODE=prod|mock
• Deploy green with processing disabled (or with outputs isolated to Temp Redis) and validate first.
• Promote by flipping the flag(s) so green becomes production-active.
• Keep rollback simple: flip the flag back to blue if required.

End-to-end validation strategy (Mock + Smoke)

A. Mock-mode validation (safe-by-design)

Objective: confirm that the new revision can process real protocol frames and produce the correct Redis outputs without mutating production state.

• Receiver (green, mock):
  • Connects to TCP source
  • Processes data
  • Writes to Temp Redis (not Prod Redis)
• Consumer (green, mock):
  • Reads from Temp Redis
  • Writes to a non‑prod DB (or a safe sink), or runs “write disabled but validate transforms” depending on your constraints

B. Smoke tests (fast post-deploy confidence check)

Objective: verify basic health signals after deployment and before promotion.

• Can Receiver connect to TCP source?
• Can Receiver write to Temp Redis?
• Can Consumer read from Temp Redis?
• Are key metrics/log events present (processing loop started, messages processed, errors below threshold)?

Promotion + rollback

Promotion

Promotion is essentially switching the new revision’s bindings/flags from mock → production, for example:

• RUN_MODE=prod
• RedisHost=ProdRedis
• PROCESSING_ENABLED=true / prod_active=true

Rollback

Rollback should be symmetrical:

• Disable green (PROCESSING_ENABLED=false)
• Re-enable blue (PROCESSING_ENABLED=true)

Because rollback is a configuration flip, it can be executed quickly and consistently, assuming your pipeline and ops checks are in place.

Closing / Takeaway

For 24×7 TCP pipelines on Azure Container Apps, blue‑green deployments can still be achieved without HTTP traffic splitting by validating new revisions through mock dependency bindings (Temp Redis) and promoting them using flag-based activation. This provides a controlled and reversible release motion while keeping production paths isolated during validation.

Disclaimer: This post describes one deployment pattern for certain always‑on TCP workloads. Results depend on workload characteristics, operational practices, and environment configuration.