How a booking marketplace cut change failures from 25% to 5% with AWS CloudFormation
A hospitality marketplace in Abuja rebuilt its booking and escrow service on AWS. It now deploys three times a week instead of twice a month, and about 5% of releases fail instead of one in four.
The problem.
Our client is a hospitality marketplace in Abuja. Customers make bookings and pay through escrow, where funds are held until the booking is fulfilled. The customers, the businesses and the payment partners all rely on that escrow process being right.
The booking and escrow service ran on servers that had been set up by hand, and nobody had documented the setup. Changes were hard to reproduce and releases were manual. The company deployed about twice a month, and about one in four releases needed an emergency rollback. Every release put a payments service at risk.
There was also no protection at the edge. About 5,000 malicious requests a day, including bot traffic and card-testing attempts, reached the application directly. That exposed the company to payment fraud and strained its relationships with payment partners.
Escrow reconciliation errors cost the team about 15 hours a month in manual correction, and each error risked a customer dispute. Left alone, fraud and escrow errors could lead to chargebacks, disputes and the loss of the payment partners the business depends on.
What we built.
Discovery first
We started with discovery. Because the old servers had no documentation, we captured their configuration and dependencies before rebuilding anything. That gave us a baseline and lowered the risk of missing a setting during the move.
Multi-tier, across Availability Zones
We then rebuilt the service as a multi-tier design across multiple Availability Zones, following the path of a request. AWS WAF filters traffic first and blocks bots and card testing before they reach the application. An Application Load Balancer routes HTTPS traffic to Amazon EC2 instances in an Auto Scaling group, which adjusts capacity to demand. Amazon RDS holds booking and escrow data in a Multi-AZ deployment, so it fails over automatically. An Amazon S3 bucket supports escrow.
Payment data protected
Payment data is protected in several ways. The load balancer uses a TLS 1.3 policy with certificates from AWS Certificate Manager and redirects HTTP to HTTPS. The database accepts only encrypted connections. The escrow bucket uses server-side encryption with a dedicated customer managed key in AWS KMS, with automatic key rotation. The root account has MFA, and AWS CloudTrail records activity across Regions to a dedicated bucket.
Infrastructure as code and fast rollback
AWS CloudFormation now defines every resource, which replaced hand-built servers with environments we can reproduce. Changes are reviewed before deployment, and AI coding assistance helped us write the templates. A CI/CD pipeline runs automated tests and offers one-click rollback, so the team can release small changes often and reverse one quickly.
Traced end to end
The API is instrumented with OpenTelemetry. Traces and metrics go to a self-hosted SigNoz instance and cover key steps such as booking reservations and escrow initialisation, confirmation and status checks. Amazon CloudWatch handles alerting.
AWS services in this engagement
The results.
The company now deploys three times a week, up from about twice a month, measured from pipeline and release history. The change failure rate is about 5%, down from about 25%, when one in four releases was rolled back.
AWS WAF blocks over 99% of the roughly 5,000 malicious requests a day, measured from WAF logs. Escrow reconciliation errors are down about 80%, measured from the monthly finance reconciliation report. Before, correcting them took about 15 hours a month.
What we learned: with no documentation, discovery mattered more than any single service choice. Writing down what the old servers did, before we touched them, is what made the rebuild safe. We also saw that frequent releases only work when rollback is fast. The one-click rollback is what made weekly releases acceptable for a payments service, so we now treat rollback as part of the first pipeline design, not a later addition.
Tell us what you're trying to ship.
A 30-minute scoping call with the engineers who would do the work.