top of page

Client Story: From Monolith to Microservices in 3 Months for an Automotive Marketplace Company

Revamping an automotive marketplace’s slowly released monolithic architecture into a microservices-based platform that is now far more resilient.

Overview

As automotive marketplaces strive to deliver personalized, scalable, and real-time digital experiences, old monolithic systems have become barriers to progress. One such company worked with Atsky to modernize its platform, moving from a single-tier monolith to a containerized, microservices-based architecture on AWS. The result? 30% faster feature releases, better system resilience, and a smoother path to partner integrations, all within 90 days.Ā Ā 



The Client


A North American automotive wholesale marketplace enables real-time auctions between used car dealers and buyers. With ambitious growth goals and an expanding partner network, including credit unions and OEM data providers, their existing system couldn't keep up.Ā Ā 


  • Business Model:Ā B2B/B2C vehicle auction & financing platformĀ Ā 


  • Users:Ā 10,000+ active dealers and agentsĀ Ā 


  • Monthly Volume:Ā 30,000+ car listingsĀ Ā 


  • Original Stack:Ā Monolithic Django + Postgres hosted on EC2Ā 


The Challenge


The client’s monolithic platform created several bottlenecks:Ā Ā 


  • Slow Feature Releases: Monthly releases due to fear of regressionsĀ Ā 


  • Scalability Issues:Ā One service failure could impact the entire applicationĀ Ā 


  • Partner Inflexibility:Ā Integrations with financing APIs were fragile and slowĀ 


  • Developer Frustration:Ā Tight coupling made onboarding and testing painfulĀ Ā 


Their goal was to replatform in under 3 months without affecting active users or revenue.Ā Ā 



Our Approach


Phase 1: Application DecompositionĀ Ā 


We ran a domain-driven analysis to break the monolith into independently deployable services. Key bounded contexts included:Ā 

Ā 

  • Auction EngineĀ Ā 

  • Dealer Onboarding & IdentityĀ Ā 


  • Vehicle Listings & PricingĀ Ā 


  • Financing & Credit FlowĀ Ā 


  • Notification & AnalyticsĀ Ā 


Each service was designed around clear API contracts with async communication via event buses.Ā Ā 


Phase 2: Infrastructure ModernizationĀ Ā 


  • Migrated from EC2 to Amazon EKS (Elastic Kubernetes Service)Ā Ā 


  • Split Postgres DB into service-specific schemas with read replicasĀ Ā Ā 


  • Introduced Kafka and EventBridge for service separationĀ Ā 


  • Centralized auth using AWS CognitoĀ Ā 


Phase 3: CI/CD Automation & ObservabilityĀ Ā 


  • Set up GitHub Actions and ArgoCD for service-level deploymentsĀ Ā 


  • Canary deployments and feature flag rollouts via LaunchDarklyĀ Ā 


  • Observability stack with Prometheus, Grafana, and LokiĀ 


  • Full-stack tracing using OpenTelemetry and AWS X-RayĀ 



The Results

KPI

Before

After

Impact

Release Frequency

Monthly

Weekly (some daily)

30%+ faster feature rollouts

Service Resilience

Single point of failure

Isolated failures

System-wide uptime improvement

Partner Integration Time

6+ weeks

<2 weeks

Faster monetization

Developer Onboarding Time

3–4 weeks

1–2 weeks

Simplified service ownership

New Revenue Features

Delayed

Continuous delivery

Enabled credit union integrations



RTO / RPO


  • Recovery Time Objective (RTO): ~10 minutes

    • Once microservices were implemented on Amazon EKS, the platform began to benefit from:

    • Kubernetes self-healing (automatic pod restarts) Service-level health checks Blue/Green or Canary deployments via ArgoCD

    • With separate service boundaries, a service can fail independently without affecting the entire system.

    • In the event of a complete EKS node failure or regional service impairment, critical functionality is resumed within ~10 minutes due to multi-AZ failover alongside auto-scaling.

  • Recovery Point Objective (RPO): ~0 to 5 minutes

    • Through layer decoupling and data replication using RDS read replicas, the system captures:

    • Near real-time backups Utilization of WAL (write-ahead logging) or point-in-time recovery Streaming data via Kafka/EventBridge ensures data in-flight is either persisted or retried

    • For non-transactional services (notifications, analytics), a combination of retries and idempotent design helps mitigate data loss.

    • Before modernisation, monolith deployment complexity would likely have led to RTO exceeding 1-2 hours. RPO suffered due to no event replay or partial backup mechanism.


Business Impact


  • Launched a new Buy Now financing option powered by OfferLogix APIsĀ Ā 


  • Rolled out real-time dealer bidding and live auction pricingĀ Ā 


  • Reduced mean time to recovery (MTTR) for bugs by 60%Ā Ā 


  • Created dedicated squads with end-to-end ownership of microservicesĀ 

Ā 

  • Built a platform culture ready for scale, partners, and experimentationĀ Ā 



ā€œThis wasn’t just a tech upgrade. We moved from one big bottleneck to a nimble, scalable platform, and we’re now shipping weekly without fear.ā€Ā ā€” CTO, Automotive Marketplace CompanyĀ Ā 



Tech Stack Highlights


  • Backend:Ā Node.js, Python (FastAPI), KafkaĀ 


  • Container Orchestration:Ā Amazon EKS, HelmĀ Ā 


  • Database:Ā PostgreSQL with read replicasĀ Ā 


  • Auth:Ā AWS Cognito, OAuth 2.0Ā Ā 


  • CI/CD:Ā GitHub Actions, ArgoCD, LaunchDarklyĀ 


  • Monitoring:Ā Prometheus, Grafana, Loki, OpenTelemetry

Ā 

  • Security:Ā IAM policies, Secrets Manager, OPA for policy as codeĀ 


Why It Matters


The shift to microservices isn’t just about fancy terms; it’s about speed, resilience, and flexibility. For this client, modernization wasn’t only technical; it unlocked new business capabilities:Ā 

Ā 

  • Faster time-to-marketĀ Ā 

  • Platform stability under growth stressĀ Ā 

  • Ability to monetize new partner APIsĀ 


Ready to Leave the Monolith Behind?


Whether you're a mobility startup or a legacy OEM, Atsky’s cloud-native modernization playbook can help speed up your transformation.Ā Ā 

Power in Numbers

Deployment Time

Real Time On Demand

Change Failure Rate

< 0.01%

Recovery Time

~10 minutes

Cloud Migration and Integrations.png

Lead Time

Dynamic

Cloud Engineering.png

Release Cadence

~2 weeks

Project Gallery

bottom of page