About AHP Tour

AHP Tour treats production engineering like tennis. Two players continuously operate separate shops that start with identical, healthy systems. They take turns choosing the next production condition, and it reaches both shops at once. A player serving a difficult condition has to live with it too. Both agree to the court’s rules before play; their code and operating decisions create the differences during the match.

The court, the ball, and the lines

The court is deliberately small: a catalogue, cart, inventory, payment, order, and fulfillment path. The application code, cache, database, and deployment tools are real; customers and money belong to the game. Both players get the same starting code, data, topology, preparation time, and resource limits, with freedom to change their own implementation.

A tournament’s infrastructure is its surface. Kubernetes, PostgreSQL, and Valkey make a balanced court. An edge/serverless/CDN court rewards fast routing and cache decisions. A stateful, queue-heavy court rewards patient recovery and backpressure. Both players always play on the same surface.

The contract also bounds combinations of conditions, their ramps and durations, and when the next one may be served. Players know the available controls and limits. Arena weather has no player behind it. The systems are isolated: each player diagnoses symptoms from their own production view, with no access to the other’s credentials or private state. Spectators can see both.

A rally

For example, A serves a 1.8× demand surge with checkout-heavy traffic. It ramps over 15 seconds and lasts 90 seconds. The referee applies it to both shops. A knows what they selected; B first sees checkout latency climbing, a nearly full database connection pool, and growing queues.

B finds unbounded retries in the payment code. They implement bounded retries with jitter and deadline propagation, run tests, and deploy a 10% canary. Old and new versions coexist while customers continue arriving. B’s shop holds the customer service target for ten continuous seconds, the stability window on this court. That is a return. B gains initiative.

B now chooses a payment-provider slowdown of 650ms, within this court’s limits. It reaches both shops. B has dependency isolation; A’s retries begin multiplying the load. A can change the hot path, introduce a circuit breaker, prioritize checkout, or buy capacity. A payment timeout also raises a correctness question: did the charge fail, or did only its reply disappear? The referee checks orders and payments independently.

Meanwhile, the arena starts a background reconciliation job on both sides. That is weather: neither player chose it. Their queues and outstanding orders survive every exchange. A restart can clear stuck connections and trigger a stampede into an empty cache; rolling back can rescue a release and restore an old bottleneck.

The customer stream and system state remain live through the exchange. Carts, queues, payments, and orders continue until the point ends; each shopper has their own 20-second purchase deadline. Players have a separate published recovery window to stabilize their system while ordinary customers keep arriving. The next point begins from the same healthy baseline, and each player keeps the lessons from the last one.

What wins a point

A correct purchase completed within 20 seconds earns $5 in game dollars. A late or rejected customer earns nothing, lowering that shop’s net result. Net revenue is purchase earnings minus infrastructure cost during the rally. When the rally clock expires, the higher net result wins the point if both shops have met the published recovery target and stayed within budget. Missing the recovery window or breaching the budget loses the point; a lost confirmed order or duplicate charge forfeits the game.

If both players miss the same evaluation or finish with tied net results, they replay the point from the same healthy baseline under the same conditions. Spend is counted for that replay. Players alternate serves between points; points make games, and games make sets. Each tournament publishes the match length and scoring rules before play.

That arithmetic makes capacity a tactical choice. An extra $160 takes 32 more correct $5 purchases just to pay for itself. A player can spend to handle a burst, but has to recover enough business to justify it. A deployment, cache policy, or decision to stop timed-out work can change the economics before the next serve.

Two kinds of engineering, one shop

The game rewards product engineering as well as site reliability. Product judgment shows up in inventory and payment correctness, data models, query costs, concurrency, transaction boundaries, and tests. SRE judgment shows up in admission control, isolation, observability, network behavior, capacity, deployment, and recovery. Both players own the whole path from customer request to fulfilled order.

No dashboard can answer every question. A green health check cannot prove that the right order was written, and a fast handler cannot help if its dependency has stopped responding. Buyers may be delayed or turned away while a fix is tested. The referee uses the underlying customer and payment state, not a player’s chosen metric.

Watching and replaying

The broadcast gives each player a mirrored view: terminal, editor, telemetry, customers, and score. A central strip shows the current production condition, time remaining, and who has initiative. Viewers can follow one buyer approaching the checkout deadline, a capacity provisioning countdown, and both players’ decisions.

A condition the receiver cannot stabilize is an ace. If the receiver handles it but the server fails under their own choice, that is a return winner. A rushed deployment that breaks a healthy checkout path is an unforced error. The commentary follows what happened to customers and why.

After the match, players and viewers can replay turning points with the information available at the time, then branch into a rollback, a capacity change, or another fix. Model comparisons can help explore what might have happened; they are material to examine, not proof. The event log and customer outcomes remain the record. This grows out of Forkalope’s SRE flight school, where engineers investigate a running service, change it, and see the result.

Other ways engineers practice and compete

Incident competitions, cloud GameDays, and troubleshooting labs already test many of these skills. The table compares their published formats. In the sites reviewed here, we haven’t found the full AHP combination: opponents choosing bounded production conditions in real time, both operating throughout, customer outcomes scored against cost, and a broadcast that follows the rally.

AHP puts two engineers on the same court, trading bounded production conditions while both keep their shops running. The score reflects correct orders and cost, and the broadcast lets viewers follow the decisions on both sides of the rally.

Andrew Arrow
andrew@ahptour.com