Armakuni Contact us
← All case studies

The biggest auction of the night
was the one most likely to fall over.

A U.S. live video auction platform ran bidding, video, chat and payments on one shared system, so its best events put everything under strain at once. We split those workloads so each scales on its own, rebuilt signup and checkout around how bidders actually pay, and automated every release.

Before

The platform came under the most strain during its highest-value events.

Bidders dropped off before they placed a bid.

After
95%less downtime across live auctions
60%more revenue
25%higher engagement

As the platform reported after cutover.

The platform came under the most strain during its highest-value events

For a live commerce platform, everything happens at once. A seller brings an audience into a live stream. Viewers become bidders, the chat speeds up, and winning buyers head to payment while the next item is already on screen.

The platform's original architecture ran video, bidding, chat, payments and inventory in one shared application, so a successful event strained all of them at once. On a popular auction, latency meant bids arrived late and didn't register, which put the moments that made the most money at the highest risk of failing.

Bidders dropped off before they placed a bid

The buying experience had its own limits. Signup was phone-only, which put off buyers used to signing in with Google or Apple. Checkout had one provider, so bidders in Europe expecting GiroPay or EPS, or mobile shoppers expecting Apple Pay or Google Pay, were pushed through a single route or left. And there were no native notifications, so followers missed the moment their favorite sellers went live.

Every release made the platform riskier because deployments were manual, done in several steps and done by hand across environments that had drifted apart from each other, and each one was a chance for an error that only showed up in production, during a live event.

The team set out to scale each part on its own and make releases routine

The fix had two parts. The team split the platform so a rush of viewers drew on video capacity and not payments capacity, and they worked to make shipping a change routine enough to happen during the week's biggest event without anyone holding their breath.

How we built it

5 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Bidding, video and payments scale separately
  2. A database bids no longer have to compete for
  3. Migrate behind the load balancer, one service at a time
  4. Signup and checkout built around how bidders pay
  5. Release gates and monitoring that follow the auction

Bidding, video and payments scale separately

Built withECSFargateLambda
One platform Bidding Video Payments
The engineering

We split the application into containerized services on Amazon ECS Fargate, separating bidding, video, chat, payments and inventory.

  • Each service scales against its own workload now, so a rise in viewers doesn't make every part of the application grow in step.
  • AWS Auto Scaling expands and contracts with real demand, which means a big event doesn't need capacity provisioned hours ahead or operators kept on standby.
  • An Application Load Balancer routes requests to healthy targets and drains traffic during deployments, so a slow service can no longer take the entry point down with it.
  • AWS Lambda handles event-driven execution and asynchronous workflows outside the main request paths.

All the features drew on the same shared resources, so the busiest one decided how well the rest performed.

A database bids no longer have to compete for

Built withRDS
One database for everything Bids: primary Reads: replicas
The engineering

The legacy database was a single point of contention, sized for a normal day. Amazon RDS replaced it. Read replicas separate catalog and analytical reads from the transactional writes that carry bids, and automated backups support recovery, replacing the manual playbook that used to follow an incident.

Migrate behind the load balancer, one service at a time

Old platformNew platform Service 1Service 1Service 2Service 2Service 3Service 3 behind the load balancer, live
The engineering

The platform couldn't stop for its own modernization, because there's always another auction, so the team introduced services incrementally behind the load balancer and shifted traffic across as the migration progressed. The cutover happened with zero downtime and no scheduled outage windows.

Signup and checkout built around how bidders pay

Built withSNS
Bidders Google, Apple, phoneWallets, Apple PaySeller-live alerts
The engineering

The product team put its effort where bidders were dropping out.

  • Google and Apple sign-in joined phone authentication, and persistent sessions mean a bidder doesn't have to keep logging back into the mobile app.
  • Checkout expanded to wallets, Apple Pay, Google Pay, GiroPay, EPS and stored cards alongside the existing payment route, and the wallet can pre-authorize funds before an event so a winning bid settles against a cleared balance instead of failing at the last step.
  • Amazon SNS sends a notification when a followed seller goes live, when an auction is about to close, or when a saved item is about to appear.
  • mParticle pulls viewing, bidding and checkout events together into one shared customer data layer, so product and marketing teams can plan re-engagement based on what actually happened in the funnel.

The team made these changes because, for an impulse purchase, every extra step between a buyer wanting an item and owning it is a chance to lose them.

Release gates and monitoring that follow the auction

Built withCodePipelineCloudWatchWAFIAMKMS
The platformTests gate every releaseCloudFormation templatesBid latency on dashboardsWAF at the edge
The engineering

We rebuilt the release path around automated checks, so every change is verified by the pipeline before it ships.

  • AWS CodePipeline automates build, test and deployment. Tests act as release gates, and rolling back a release is one defined operation.
  • AWS CloudFormation keeps the infrastructure in version-controlled templates, so development, staging and production are provisioned the same way instead of drifting apart over time.
  • Amazon CloudWatch dashboards and structured logs track bid latency, payment success, video quality and concurrent users, with alerts tuned to live-event demand, so operations gets signals that general server metrics never would.
  • AWS WAF protects the public edge against bot traffic and scraping, IAM roles limit service access, and AWS KMS and AWS Certificate Manager handle encryption and certificates.

What we'd tell another CTO

1Separate the paths that carry revenue first. Bidding and payments should never wait behind video or chat, and once they had their own services, a busy event cost video capacity rather than bids.
2Monitor the signal the business feels. Bid latency and payment success show an auction in trouble long before CPU or server load does, which is why the alerts were tuned to them.
3The team put the gates, the templates and the one-step rollback in place first, and that is what let them reach 100 deployments a week.

What else changed

As the platform reported after cutover.

  • Infrastructure cost fell 15%, from containerized services, auto-scaling sized to real demand and managed services.
  • 100+ deployments a week through the automated pipeline.
  • A zero-downtime cutover, with services migrated behind the load balancer while auctions kept running.

What comes next

The platform also uses AI agents for personalized live-event recommendations, real-time fraud detection during high-value auctions and catalog enrichment for sellers.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

Today AK Evolve would pin the auction rules with characterization tests before any service left the monolith, because bidding rules are exactly the kind nobody writes down, and AK AI Factory's linters would stop anyone wiring two services back together afterwards, with the four DORA measures of delivery visible from the first weeks. For the fraud detection on the roadmap, the AI agent watching high-value bids would get its own identity and Cedar policies checked on every tool call, and a golden set of past auctions, fraud included, would gate every change.

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop