Armakuni Contact us
← All case studies

A ten-minute change took days to ship,
because it had to reach 400 auction houses by hand.

A global white-label auction platform runs live sales for more than 400 branded auction houses, handling thousands of bids a minute. We split the live-auction services apart, folded each house's configuration into one release pipeline, moved partners onto queued events, and gave every tenant one identity system while keeping its data separate, because every release used to mean carrying each house's branding and settings across by hand.

Before

Every release went out four hundred times.

The biggest sale carried the most risk.

After
99.9%uptime at thousands of bids a minute
100+deployments a week
30%faster auction-house onboarding

As the platform reported.

Every release went out four hundred times

Each auction house has its own branding, feature settings and partner connections for payments, identity checks, shipping and marketing. Engineers had to carry those differences through every release by hand, without disturbing a live sale, which meant a ten-minute change could take days to reach every instance, and release frequency was capped at a handful a month.

The biggest sale carried the most risk

An auction house's biggest events are also the platform's biggest revenue moments, because real money gets bid in real time. Bidding, payments and inventory lived in one application and could only scale together. Partner integrations were wired straight into the core, which meant a misbehaving payment or shipping provider could affect bidding. Because authentication was handled separately on each instance, compliance reviews grew longer with every new auction-house contract.

One pipeline now handles every auction house's configuration

We started treating the 400 auction houses as one product with 400 configurations, where before there had been 400 separate products. A release gets built once, the pipeline applies each house's settings on top of it, and the live-auction services stay apart from the partner connections so neither can take the other down.

How we built it

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

  1. Bidding, payments and inventory now run as separate services
  2. The pipeline applies each auction house's configuration
  3. Partner connections now go through a queue
  4. One identity system now serves every tenant, with each tenant's data kept apart

Bidding, payments and inventory now run as separate services

Built withECSFargateRDS
One application Bidding Payments Inventory
The engineering
  • Bidding, payments and inventory became containerized services on ECS and Fargate, so capacity and releases follow each service's own needs, and a payments security fix no longer waits behind a bidding feature.
  • Auto-scaling absorbs peak auction load, so big sales no longer need capacity provisioned days ahead with operators on standby.
  • The database work moved the legacy Oracle workload to an Amazon RDS environment with tenant-aware data handling.

The services that handle bidding and payments run on capacity dedicated to them, so other parts of the system can't pull it away.

The pipeline applies each auction house's configuration

Built withCodePipelineCloudFrontS3
One changeThe pipeline applies each houseMore than 400 deployments
The engineering

Configuration-driven pipelines manage branding, feature flags and environment settings across more than 400 deployments. A shared release uses each auction house's configuration, with no separate manual release procedure per house. CodePipeline and CodeBuild automate delivery, and CloudFront serves the branded assets stored in S3. Monitoring tracks every release against the operational and security controls auction houses are audited on.

Partner connections now go through a queue

Built withSNSSQSEventBridge
Bids and checkoutLive Partner events Queued
The engineering

SNS, SQS and EventBridge carry the message-based integration model. Payment, identity, shipping and marketing connections exchange standardized events instead of adding another direct dependency to every service. Queued communication also lets the platform handle a delayed partner separately from the live bidding path, so a partner outage is contained instead of cascading.

This matters because in a live auction, a slow shipping partner can't be allowed to slow down the bidding.

One identity system now serves every tenant, with each tenant's data kept apart

Built withCognitoIAM
One identity system HouseHouseHouse each tenant's data kept apart
The engineering

Cognito centralizes authentication, so credential rotation, MFA and access policy get set once instead of 400 times. IAM and per-tenant data controls keep each white-label customer's data apart, with separation enforced rather than logical. That replaces the work of maintaining a separate identity setup for each branded instance, and gives large auction houses' legal teams the isolation they ask for.

What we'd tell another CTO

1We treat white-label customers as configuration rather than as separate builds, which means one release carries all their different settings. The revenue services stay isolated from each other, so bidding and payments can scale and ship on their own schedule. A queue sits between the platform and every partner, because a delayed partner should never be able to reach the live path.
2We centralize identity and keep each tenant's data separate, with one login system and boundaries the platform enforces per tenant. Every release gets checked against the audit controls, which means the evidence for the next review comes straight out of the deploy itself.

What else changed

As the platform reported.

  • No security breaches since cutover, with centralized identity and isolated data.
  • Partner outages contained, on a queued event model.

What comes next

Ongoing platform engineering on the same release model, with more auction houses and partners joining through configuration.

How we'd do it today

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

Auction rules are exactly the kind nobody wrote down, so the services would be cut out with AK Evolve: AI agents read the old code into specs, characterization tests pin what it does today, and each service is rebuilt against those tests behind a routing layer, going live on its own with a way back. Releases would reach a small share of the 400 auction houses first and roll back on their own if quality, speed or errors cross a line agreed in advance, with the four DORA measures of delivery visible from the first weeks.

AK Run's AI agents would take the first look at every alert and draft the fix, for a named engineer to confirm and ship with a test through the platform's own pipeline, and we'd own each security finding until a tested fix is live.

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