Order platform: SaaS or lift-and-shift?

Start with the binding constraints, not the technology. The SaaS option meets the availability target on paper but cannot satisfy Brazilian data residency because the vendor has no Brazilian region; a local partner or a future region would be needed, and neither is committed. At nine times peak, per-order pricing also creates a cost curve that is difficult to cap at 12%, and egress or API integration fees are unresolved. The IaaS lift-and-shift preserves the existing transactional application and lets the retailer place workloads and managed databases in EU and Brazilian regions. Its weakness is operational: the team lacks Kubernetes skills, so the design should avoid self-managed Kubernetes and use managed containers or managed application hosting plus a managed database. Recommend IaaS for the first release with a regional data architecture, contractual exit points, and a proof of SaaS only for non-Brazilian markets after residency and unit-cost tests. This follows focus on value, start where you are, and think and work holistically; it does not treat 99.95% availability as sufficient when residency and cost are non-negotiable.

Translate the business constraint into service level objectives: p95 checkout response below 300 ms per region, monthly availability of 99.95% for the checkout transaction, and an error budget of about 21.6 minutes per month. Measure both synthetic checkout transactions from each region and real-user monitoring, because synthetic tests miss payment-provider and identity dependencies. The provider is responsible for the cloud infrastructure, network, managed database availability and physical security; the retailer remains responsible for application configuration, autoscaling policy, identity and access management, data classification, release quality and payment-provider integration. Exclusions must be explicit: scheduled maintenance notified in advance, customer-side network failures, third-party payment outages, and load above an agreed test profile. Put these in the service level agreement and internal OLAs. The reasoning is that a single availability number hides where the boundary sits; without a responsibility matrix, both parties will assume the other monitors database failover, key rotation and latency at the edge. Service level management only works when the objective, measurement method and exclusions are agreed before the peak.

The catalogue entry should describe a service offering, not a server. Include: offering name and business outcome; customer segments and ordering process; service hours and support channels; service level objectives and reporting cadence; price model including per-order, egress and regional surcharges; data residency and retention; shared-responsibility matrix; dependencies such as payment providers and identity; request and change procedures; recovery objectives; and exit or data-return terms. The most important fields are residency, unit price and responsibility, because those are the three areas where the board set constraints and where Finance and legal teams will ask questions. A technically complete entry that omits per-order cost or Brazilian residency will create false expectations and later disputes. Use service catalogue management to keep the entry owned and reviewed, and service level management to keep the objectives consistent with the agreement. The catalogue is a visibility tool: if customers cannot see what is included and excluded, they will infer availability and responsibility incorrectly, which undermines value co-creation.