CH17-03: Target Architecture for Workflows, Queues, and Inventory Visibility

Goal

This section sketches a target Azure architecture for inventory and fulfillment automation. It shows how workflow orchestration, durable messaging, operational stores, dashboards, alerts, and integration boundaries work together.

The previous section named the states the business must trust. This section turns those states into an architecture.

The Short Version

Back-office architecture needs durable flow, visible state, and controlled integration.

For this chapter, do not start by asking, Which Azure service should I use? Start by asking what the operational work needs:

• A way to accept order, return, and demand signals without blocking the storefront.

• A way to track long-running workflow state.

• A way to send reliable commands to inventory, warehouse, carrier, supplier, finance, and support systems.

• A way to publish status changes and alerts.

• A way for operators and support teams to see what happened and what needs action.

Azure services are useful when they match those jobs.

A Target Architecture

Here is a practical starting pattern.

Storefront, order, return, and demand signals
	|
	v
Event routing and durable command queues
	|
	v
Workflow orchestration
	|
	+-- Inventory service and operational store
	+-- Warehouse integration boundary
	+-- Carrier integration boundary
	+-- Supplier and purchasing integration boundary
	+-- Finance, refund, and adjustment boundary
	|
	v
Operational dashboards, alerts, analytics, and exception queues

This is not a product diagram yet. It is a responsibility diagram. The exact services depend on the workload, but the responsibilities are stable.

Where Azure Services Fit

The following table maps common Azure capabilities to the jobs they perform in this architecture.

You do not need to use every service in every design. The point is to choose services by responsibility. A simple workflow might use Service Bus and Functions. A more integration-heavy workflow might use Logic Apps. A process that needs custom stateful orchestration might use Durable Functions. A high-volume operational service may run in Container Apps or App Service.

Decoupling The Storefront

The storefront should not directly call every back-office system during checkout.

Instead, the customer-facing path should record the business intent and hand off durable work. For example:

Checkout accepts order
	-> order record is created
	-> order event or command is emitted
	-> fulfillment workflow reserves and allocates inventory
	-> warehouse and carrier steps continue asynchronously
	-> customer status updates as milestones complete

This keeps checkout responsive while still preserving accountability. The order does not vanish into an invisible background job. It becomes a workflow with state, correlation identifiers, retry behavior, and dashboards.

Workflow, Queue, Or Event

These terms are easy to blur, so separate them by job.

A back-office design often uses all three. An order event may start a workflow. The workflow may place commands on queues. Handlers may publish events when state changes. Dashboards may read the workflow and operational stores.

Operational Stores And Dashboards

A back-office architecture needs two kinds of data views.

The system-of-record view protects important state transitions such as reservations, allocations, returns, adjustments, and approvals. It should be designed for correctness, concurrency control, access control, and audit.

The operational visibility view helps teams see what is happening: queue depth, delayed orders, failed warehouse updates, stale supplier feeds, carrier errors, exception counts, stockout risk, and customer-impacting incidents. It may be fed by events, logs, workflow state, and operational stores.

Both views matter. If the system records correct state but operators cannot see risk, recovery will be slow. If dashboards are fast but state is untrustworthy, the business will make bad decisions quickly.

Example: Order Fulfillment Flow

An order event arrives after checkout.

1. The fulfillment workflow starts with the order identifier and correlation identifier.

2. The inventory service attempts reservation using an idempotent command.

3. The allocation step chooses a warehouse based on stock, delivery promise, capacity, and cost.

4. A warehouse task is created through an integration boundary.

5. A carrier label request is sent through a carrier adapter.

6. Customer notification is triggered when milestone events occur.

7. If a step fails, the workflow retries, pauses, compensates, or sends the item to an exception queue.

8. Dashboards show order progress, stuck steps, failed integrations, and customer-impacting delays.

The important design choice is not simply use a queue. The important design choice is that every step has state, ownership, and a recovery path.

Common Mistakes

• Using a simple queue when the business process needs visible workflow state. Queues hold work, but they do not automatically explain where a long-running order is stuck.

• Calling every back-office system directly from checkout. This couples customer latency to slow or fragile operational dependencies.

• Treating events as commands. An event says something happened; a command asks a specific responsibility to do work.

• Omitting dashboards and replay paths from the design. Production operations need investigation and controlled recovery, not only automated retries.

• Choosing Azure services by name instead of by responsibility.

If Someone Asks You

What would an Azure back-office automation architecture include?

It would separate the storefront request path from operational fulfillment work. I would use durable messaging for commands, event routing for status changes, workflow orchestration for long-running processes, operational stores for trusted inventory and exception state, integration boundaries around warehouse, carrier, supplier, finance, and support systems, and Azure monitoring for dashboards and alerts. The design should make state, failure, ownership, and recovery visible.

What You Should Remember

Durable operational work needs both messaging and state visibility.

Questions to Check Your Understanding

1. When is a workflow engine more useful than a plain queue?

2. What systems should be behind API boundaries?

3. Which operational dashboards are needed from day one?