Armakuni Contact us
← All case studies

One national promotion from a retail partner
could multiply the platform's traffic within hours.

A U.S. automotive commerce platform brings major retail partners, dealers, lenders and insurers together into one branded car-buying experience. Traffic sat flat for weeks, then a partner's campaign sent it surging, and every new partner meant setting up branding, access and data by hand. We put the platform on ECS with autoscaling, gave each partner tenant standardized provisioning, enforced data separation between tenants and joined marketing to one customer record.

Before

Weeks of quiet traffic, then a partner's promotion.

Large partners wanted their own brand and their data kept apart.

After
99.99%availability through promotional peaks
40%faster partner onboarding
75%more efficiency in the marketing pipeline

As the platform reported.

Weeks of quiet traffic, then a partner's promotion

The platform turns a retail partner's customers into car buyers, leasers and trade-ins, working with dealers, lenders and insurers behind the scenes. Its traffic is uneven: quiet for weeks, then multiples of normal within hours when a partner runs a national promotion. The old infrastructure was sized for an ordinary day, and scaling meant operators adding capacity by hand, mid-event.

Large partners wanted their own brand and their data kept apart

Large partners put their brand on the experience, and their legal teams treat customer-data exposure as a deal-breaker. Tenant data was separated only logically, which doesn't satisfy that review. And a signed partnership still left engineers with branding, environment setup, access controls and marketing workflows to configure by hand. Meanwhile leads from expensive promotions could go weeks without a follow-up.

Make each partner a standard tenant

We treated each partner as a standard tenant, provisioned with its own data boundary, branding and access, and made capacity and follow-up automatic, so a promotion brings in customers without putting the platform at risk.

How we built it

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

  1. Capacity that follows the campaign
  2. Provisioning a tenant instead of building one
  3. Leads that don't go cold

Capacity that follows the campaign

Built withECS
one promotion, traffic multiplied Campaign trafficCapacity
The engineering

ECS orchestrates the containerized services, with autoscaling tuned to promotional traffic, so each service scales on its own rather than the whole platform growing together, and the pre-provisioning that used to eat into operations time before every partner promotion is gone. The disaster-recovery design carries a one-hour recovery-time objective, built into the architecture and exercised regularly, which gives a partner contract a recovery commitment it can hold the platform to.

Partners judge the platform during their promotions, and capacity added after the spike has passed doesn't help anyone.

Provisioning a tenant instead of building one

Built withDynamoDBAuroraSecurity HubCloudWatch
A new partner, provisioned TenantTenantNew tenant per-tenant access and permissions
The engineering
  • Standardized provisioning replaces repeated manual setup for each partner tenant, covering environment configuration, branding and access controls.
  • DynamoDB-backed tenant handling and application permissions govern access, with per-tenant separation enforced at the data layer rather than only in application logic.
  • Aurora holds customer and transaction data, personal information included, with continuous encryption, so its protection comes from the architecture.
  • Security Hub centralizes findings, Config evaluates infrastructure configuration continuously and CloudWatch supplies the operational view. Compliance evidence builds up as the platform runs, which means a misconfiguration gets caught at the platform layer before an audit finds it, and a partner's compliance review can be answered straight from the platform.

Leads that don't go cold

Built withIterable
One record Iterable nurturingMarketingSales one shopper, not three
The engineering

An Iterable integration automates multi-step lead nurturing and partner-branded campaigns across every brand at once. A customer-management integration provides one shared record across the marketing and sales workflow, so a shopper isn't three different people in three systems, which cuts duplicate outreach and missed handoffs.

One promotion, end to end

  1. A retail partner launches a national campaign at 9 a.m.
  2. Traffic climbs to many times normal, and autoscaling adds capacity to the busy services as it happens.
  3. Shoppers browse vehicles in the partner's branded experience, inside that partner's tenant boundary.
  4. A shopper starts a financing application, and the data goes to Aurora, encrypted, visible only within that tenant.
  5. They leave without finishing, and Iterable sends the partner-branded follow-up the next morning, from the shared customer record.
  6. By evening, capacity scales back down again.

What we'd tell another CTO

1Size the platform for a partner's national promotion, because that afternoon is when the partner decides whether to stay, not an ordinary Tuesday. A hand-built partner can't scale with sales, so each tenant needs to be a provisioning step too.
2A big partner's legal review wants separation enforced in the data layer as well as in application logic, and compliance evaluated continuously, because evidence assembled before an audit has already drifted. The lead loop also needs closing, because paying to bring shoppers in is wasted if nobody follows up.

What else changed

As the platform reported.

  • A one-hour recovery-time objective, built in and exercised.
  • Enforced tenant separation, with continuous compliance evaluation.

What comes next

More partner brands onboarded through the same provisioning, and the shared customer record extended across the dealer and lender workflows.

How we'd do it today

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

Through each promotion, AK Run's AI agents would take the first look at every alert and draft the fix, and a named engineer would confirm the cause and ship it with a test, with one team running the cloud, the applications and the security day and night. On AK AI Factory, an AI agent drafting follow-ups would get its own identity, only the tools its job needs and one partner's tenant in reach at a time, through Cedar policies checked outside the model on every call.

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