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.