---
title: "Real-life scenario: Global Sales Connect"
chapter: "12"
---

# Real-life scenario: Global Sales Connect

This fictional scenario mirrors the responsibilities in the role
description without claiming to describe Hilti's internal architecture.

## The situation

BuildCo sells equipment in 60 countries. Customers use web and mobile channels.
Sales teams use Salesforce, orders and product prices live in SAP, employees
and territories come from Workday, and marketing needs trusted customer events.
Peak campaigns create ten times normal traffic.

The goals are faster customer experiences, no duplicate orders, regional
resilience, controlled personal data, and a platform that teams can extend.

## Questions before services

- Which system owns customer, product, price, employee, consent, and order data?
- Which countries require data to stay in a particular location?
- What are the checkout RTO, RPO, and latency targets?
- Can SAP accept bursts, or must requests be buffered?
- Which integrations need immediate answers and which can be eventual?
- How will duplicate and out-of-order events be handled?

## Proposed architecture

CloudFront and WAF protect and accelerate the customer channel. Route 53 directs
traffic. The regional application runs stateless services on ECS Fargate across
three AZs behind an Application Load Balancer. API Gateway publishes partner and
channel APIs.

Aurora stores channel transactions that require relational consistency.
DynamoDB stores high-volume idempotency keys and session-like state. S3 stores
documents, events, and the analytics lake.

The application emits business events to EventBridge. SQS queues isolate SAP
order processing and absorb campaigns. Step Functions coordinates long-running
order steps. Failed messages go to a dead-letter queue with alarms and a replay
runbook. Every command carries a correlation and idempotency key.

Salesforce customer changes move through AppFlow for managed bulk/scheduled
data movement and EventBridge/API patterns where timely operational events are
needed. SAP exposes governed APIs or OData; AppFlow can serve supported OData
flows, while orders use a controlled integration service and queues. Workday
employee and territory changes enter through approved Workday APIs or encrypted
files, then become normalized business events. No system reads another system's
database directly.

## Security and governance

Production, non-production, network, security, and log archive live in separate
accounts governed by Control Tower. IAM Identity Center federates people.
Workloads use roles. KMS encrypts data, Secrets Manager stores credentials,
CloudTrail and Config feed the security account, GuardDuty and Security Hub
raise findings, and Macie helps inspect sensitive S3 data.

## Reliability and operations

Multi-AZ is the normal operating design. The business chooses warm standby in a
second Region for checkout after comparing cost with the RTO/RPO. Aurora and S3
data follow tested replication/backup plans; Route 53 failover is exercised in
game days. CloudWatch dashboards show checkout success, queue age, SAP failure
rate, latency, error budget, and cost per order.

## Trade-offs

- Asynchronous SAP writes protect SAP and improve scale, but order confirmation
  becomes “accepted” before final completion.
- Multi-Region improves recovery but doubles many operational paths.
- AppFlow reduces integration code for supported flows, but custom rules still
  belong in owned services.
- Fargate reduces host operations but should be compared with EC2 at steady,
  large scale.

## Delivery roadmap

1. Establish landing zone, identity, logging, network, and cost allocation.
2. Deliver customer read journeys with cached product data.
3. Add the queued order path with reconciliation and failure replay.
4. Integrate Salesforce and Workday through owned contracts.
5. Add analytics, DR rehearsal, optimization, and regional expansion.

## Evidence of success

Measure checkout availability, p95 latency, duplicate orders, reconciliation
exceptions, mean recovery time, security findings age, deployment frequency,
and cost per successful order.