Platform engineering is having a moment. The concept — a dedicated team building the internal tools, abstractions, and "paved roads" that product engineers use to ship software — has moved from a boutique practice at FAANG companies to a mainstream discipline. But most of the writing about it describes either the organizational theory or toy examples. What does it actually look like to build a platform that needs to handle tens of thousands of requests per second, across a multi-tenant architecture, with the expectation that it will not go down during the most commercially critical moments of the year?
E-commerce infrastructure is a useful case study because the requirements are extreme in specific ways: traffic patterns that are deeply non-linear (Black Friday spikes can be 10-100x baseline), availability requirements that are directly tied to revenue-per-second, and a multi-tenant architecture where one merchant's behavior can affect others if the platform isn't carefully isolated.
Here's what platform engineering looks like when you're solving those constraints.
The Platform Contract
The most important artifact a platform team produces isn't code — it's the contract it makes with its users (product engineering teams). The contract defines:
- What the platform provides (compute primitives, databases, queues, CDN, build and deploy tooling)
- What guarantees the platform makes (availability SLAs, data durability, deployment time)
- What the product team is responsible for (their application code, their data model, their response to their own availability alerts)
- What the platform team will not provide (custom infrastructure for one team's specific requirements)
Without an explicit contract, platform teams end up doing everything for everyone, which means they do nothing particularly well. The contract is how you scale a small platform team to support hundreds of product engineers.
For multi-tenant platforms, the contract also needs to address isolation: how are tenants protected from each other's behavior? If one tenant runs an expensive database query that degrades performance for others, who owns that? The answer has to be in the contract.
Traffic Management for Non-Linear Load
The canonical e-commerce challenge is Black Friday. Your traffic forecast for peak events is imprecise, the stakes of underprovisioning are high (direct revenue loss during the hours your traffic is highest), and the cost of overprovisioning is real but secondary.
The platform's job is to make this problem tractable for product teams. The mechanisms:
Autoscaling with pre-warming. Standard autoscaling reacts to observed load. For predictable peaks, you want proactive scaling — expanding capacity ahead of the anticipated traffic. This requires a capacity planning process where the platform team works with the business on expected traffic forecasts and pre-scales the fleet before the event begins. Post-event scale-down is equally important; leaving the fleet at 10x baseline after the event is expensive.
Traffic shaping at the edge. A CDN layer that can absorb static asset requests and cache product pages protects the origin infrastructure. The platform team owns the CDN configuration and the caching rules. Product teams own the cache-control headers on their responses. Both need to understand each other's behavior or cache invalidation bugs surface at the worst possible time.
Circuit breakers and graceful degradation. When a downstream service (inventory, pricing, payment) is degraded, the product layer needs a graceful degradation path. Platform teams can provide circuit breaker libraries and patterns, but the degradation behavior — what does the product show when inventory data is unavailable? — is a product decision, not a platform decision. The platform team's job is to make it easy to implement degradation, not to decide what degradation looks like.
Load shedding policies. At extreme scale, you need a defined policy for what happens when the system can't keep up. Queuing all excess requests leads to cascading failures when the queue grows without bound. Shedding requests — returning 503s intentionally — is a stability mechanism, not a failure. Platform teams should implement load shedding at the infrastructure layer so product teams don't have to.
The Multi-Tenant Isolation Problem
Multi-tenant platforms have a fundamental tension: efficiency (sharing resources across tenants is cheaper) versus isolation (one tenant's behavior affecting others is unacceptable). Platform engineering is largely the discipline of managing this tension.
Noisy neighbor mitigation. The most common isolation failure is the noisy neighbor: one tenant running an expensive operation (a large database query, a bulk export, a background job) that consumes shared resources and degrades response times for everyone else.
Mitigation strategies: rate limiting at the tenant level, separate resource pools for background vs. interactive workloads, priority queuing that de-prioritizes bulk operations relative to interactive requests, and database query analysis that identifies and throttles expensive queries before they affect the cluster.
Blast radius containment. When something does go wrong — a tenant deploys bad code, a bad query brings down their database, a runaway process consumes CPU — the platform's job is to contain the blast radius. Cell-based architectures are the canonical solution: partition your tenant population across independent cells, each with its own infrastructure. A failure in one cell affects that cell's tenants, not everyone.
Cell-based architecture adds operational complexity (you're now managing N independent infrastructure stacks instead of one), but the blast radius reduction justifies it at scale. The platform team owns the cell assignment logic and the cross-cell routing.
The Deploy System as a Platform Product
Product engineers spend more time interacting with the deployment system than with any other platform product. The deploy experience — speed, reliability, observability, rollback capability — directly affects developer productivity.
At e-commerce scale, the deploy system has additional requirements:
Deployment windows. You cannot deploy to production during peak traffic hours. The platform enforces deployment windows: deploys are blocked during high-traffic periods and automatically queued for the next available window. This requires integration with the traffic forecasting system — the deployment system needs to know when "now" is a peak period.
Progressive rollout with business metrics. Standard canary deployments roll out by traffic percentage and watch error rates. E-commerce deployments need to also watch business metrics: conversion rate, cart abandonment, revenue per session. A deploy that doesn't increase error rates but causes a 5% drop in conversion has caused a very real business impact that technical metrics alone won't catch.
Fast rollback. When a deploy causes an issue, the MTTR is measured in minutes of revenue impact. Rollback must be fast — ideally under 60 seconds. This requires a deploy architecture where rolling back is as simple as deploying the previous version, with pre-baked images and fast traffic routing updates.
AI in the Platform Layer
The platform team is uniquely positioned to deploy AI tooling that benefits all product teams simultaneously. Rather than each product team building their own AI-powered tools, the platform provides:
AI-powered deploy risk scoring. Before a deploy goes out, an ML model scores its risk based on the size of the diff, the services touched, the time of day, recent incident history for the service, and the deployment frequency of the team. High-risk deploys get flagged for extra review; low-risk deploys can be fast-tracked.
Automated remediation patterns for known failure modes. Platform teams have the deepest knowledge of how infrastructure fails. That knowledge, encoded as safe automation and explained in public technical posts, can be exposed as a platform service that product teams benefit from automatically.
Cost attribution and recommendations. The platform team sees all infrastructure costs. AI-powered cost analysis that attributes costs to teams and services, and surfaces specific optimization opportunities, is a high-value platform offering that no individual team could build for themselves.
The platform team that builds these capabilities creates leverage across the entire engineering organization. That's the compounding return on platform engineering investment.
*Zak Hassan is a Staff SRE specializing in platform engineering, data platform reliability, and AI-powered infrastructure automation. Find him at zakhassan.com or on LinkedIn.*
Topic Paths