CH17-06: Back-Office Automation and Inventory Scenario

Goal

This section applies the chapter model to a large Azure commerce platform that needs inventory updates, warehouse tasks, replenishment, returns, shipping events, exception queues, and operational alerts.

The goal is not to memorize one perfect reference architecture. The goal is to learn how to explain back-office automation as a design that turns customer promises into durable operational work.

The Short Version

A strong back-office scenario answer explains how customer promises become durable operational work.

In an architecture conversation or design review, do not start with a list of services. Start with the business flow: orders, returns, and demand signals must move through inventory, fulfillment, warehouse, shipping, supplier, finance, support, and analytics responsibilities without making checkout wait on every operational dependency.

Then explain the architecture choices: decouple the request path, use durable messaging and workflow state, protect inventory transitions, integrate through controlled APIs, make exceptions visible, secure sensitive actions, and assign ownership for recovery.

Scenario

A large e-commerce marketplace runs web, mobile, seller, warehouse, finance, support, and partner experiences on Azure. The company wants to automate back-office operations without coupling every storefront action directly to warehouse, carrier, supplier, and finance systems.

The platform must support:

• Inventory availability, reservation, allocation, and replenishment.

• Warehouse pick, pack, inspection, and exception tasks.

• Carrier label requests, shipment tracking, delays, and delivery updates.

• Returns, refunds, restocking, repair, disposal, and fraud review.

• Supplier feeds, purchase triggers, and replenishment approvals.

• Operational dashboards for stockouts, stuck orders, failed integrations, and customer-impacting incidents.

• Security, audit evidence, data quality, and ownership across many teams.

Architecture Sketch

One reasonable Azure architecture looks like this.

Storefront, order, seller, return, and demand signals
	|
	v
API and event boundary
	|
	+-- Order accepted events
	+-- Return requested events
	+-- Demand and stock signals
	|
	v
Durable messaging and workflow orchestration
	|
	+-- Reservation workflow
	+-- Allocation workflow
	+-- Warehouse task workflow
	+-- Shipping workflow
	+-- Return and refund workflow
	+-- Replenishment workflow
	|
	v
Operational services and stores
	|
	+-- Inventory state store
	+-- Fulfillment state store
	+-- Exception queue and review tools
	+-- Audit and operator notes
	|
	v
Integration boundaries
	|
	+-- Warehouse management systems
	+-- Carrier APIs
	+-- Supplier and purchasing systems
	+-- Finance and refund systems
	+-- Customer support systems
	|
	v
Dashboards, alerts, analytics, and customer communication

In Azure terms, the design may use Service Bus for durable commands, Event Grid for event routing, Durable Functions or Logic Apps for long-running workflow coordination, Functions or Container Apps for handlers and integration adapters, Azure SQL Database or Cosmos DB for operational state depending on data needs, Key Vault and managed identities for secure access, and Azure Monitor with Application Insights and Log Analytics for observability.

Those names are not the answer by themselves. They are useful because they match the responsibilities in the diagram.

Main Design Decisions

Separate checkout from fulfillment

Checkout should record the order and create a durable handoff. It should not synchronously complete every warehouse, carrier, supplier, and finance step before responding.

That does not mean checkout ignores correctness. It still needs fraud checks, payment boundaries, reservation rules, and clear customer status. The separation means slow operational work continues through workflows that can be monitored and recovered.

Protect inventory state transitions

Availability, reservation, allocation, shipment, return, and replenishment should be separate states. Reservation and allocation need concurrency control and idempotent commands. Return and refund steps need audit evidence and sometimes human approval.

Use workflow where the process has memory

A simple queue is useful for durable work, but fulfillment usually needs process memory. The workflow should know what has happened, what is pending, what timed out, what failed, and what the next safe action is.

Integrate through boundaries

Warehouse, carrier, supplier, finance, and support systems should sit behind controlled APIs or adapters. This keeps internal workflow logic from being scattered across many direct dependencies and makes retries, authorization, monitoring, and versioning easier to manage.

Treat exceptions as designed work

Exception queues should have reason codes, owners, severity, customer impact, operator notes, audit history, and safe recovery actions. Human review is part of the architecture, not a side process.

End-To-End Flow

Here is how a normal order might move through the design.

1. The storefront accepts checkout and records the order.

2. The order service emits an order accepted event or fulfillment command.

3. A workflow starts and attempts inventory reservation with an idempotent command.

4. Allocation chooses a warehouse or seller based on inventory, delivery promise, capacity, and cost.

5. The workflow creates a warehouse task through an integration boundary.

6. The warehouse system returns pick and pack status events.

7. The shipping workflow requests a carrier label and tracks carrier events.

8. Customer status is updated from workflow milestones, not guessed from one database field.

9. Dashboards show delayed steps, failed integrations, exception age, and delivery promises at risk.

10. Analytics receives operational data for planning, forecasting, and improvement.

The same pattern can support returns and replenishment. A return request starts a workflow. Inspection determines whether the item is restocked, repaired, disposed of, or sent to review. Replenishment uses demand and stock signals, but may require approval before creating supplier commitments.

Failure Modes And Recovery Paths

A strong scenario answer includes failure modes. For example:

The pattern is consistent: detect the problem, preserve state, decide what is safe, assign ownership, and communicate impact.

Security, Compliance, And Ownership

Back-office automation should be secured by design.

Use managed identities for Azure workloads where possible, Key Vault for secrets that must exist, least-privilege access for workflow operations, and separate permissions for viewing, approving, replaying, and administering. Sensitive actions such as inventory adjustments, refund approvals, supplier commitments, replay operations, and manual overrides should be auditable.

Ownership should be explicit:

The architecture should make these boundaries visible so incidents do not become ownership debates.

Architecture Conversation Answer Structure

If you are asked to design this system, answer in this order:

1. Start with the business flow: orders, returns, inventory, fulfillment, shipping, suppliers, exceptions, and customer communication.

2. Separate the customer request path from operational workflows.

3. Name the key states: availability, reservation, allocation, warehouse progress, shipment, return, replenishment, and exception.

4. Sketch the architecture: API boundary, events, durable queues, workflow orchestration, operational stores, integration adapters, dashboards, alerts, and analytics.

5. Explain reliability: idempotency, retries, timeouts, compensation, exception queues, human review, replay, and audit.

6. Explain operations: data quality checks, dashboards, security, ownership, and runbooks.

7. Discuss trade-offs: latency versus correctness, automation versus review, near-real-time visibility versus strong state transitions, and service simplicity versus workflow visibility.

This answer shows architectural thinking instead of only naming Azure services.

Common Mistakes

• Designing only the happy path. Real fulfillment includes missing stock, delayed carriers, stale supplier feeds, return disputes, and manual approvals.

• Treating inventory state as a simple cache. Some inventory views can be cached, but reservation, allocation, adjustment, and return decisions need trustworthy state.

• Forgetting exception ownership, manual review, and customer support visibility. A hidden exception eventually becomes a customer experience problem.

• Letting checkout call every operational dependency directly. This makes storefront reliability depend on systems that should be behind durable workflows.

• Ignoring data quality and audit evidence until finance, compliance, or operations asks for it.

If Someone Asks You

Design back-office automation and inventory management for a large Azure e-commerce platform.

I would separate storefront checkout from fulfillment workflows. Checkout records the order and hands off durable work. Back-office workflows handle reservation, allocation, warehouse tasks, shipping, returns, replenishment, and exceptions through Service Bus-style durable messaging, workflow orchestration, operational state stores, and integration boundaries around warehouse, carrier, supplier, finance, and support systems. The design needs idempotent commands, retries, compensation, exception queues, human review, dashboards, alerts, audit evidence, and clear ownership so every promise and failure has a recovery path.

What You Should Remember

Back-office automation succeeds when every promise, state change, failure, and exception has an owner and a recovery path.

Questions to Check Your Understanding

1. What should be decoupled from the storefront request path?

2. Which failure modes should the architecture explain?

3. How would you explain the design in two minutes?