Discuss a project

DL-STB-04 · Stabilize / Performance

Scaling and performance for commerce apps

When orders, accounts or data grow, the app slows down and the cloud bill climbs. We find where the load really goes and fix it in the code, the database and the queues, not with a bigger server.

Discuss a project Scope
51.4344.0060°02STABILIZEDETAIL 02 · STABILIZE · DL-STB-04

Where commerce apps hit their scaling limit

  1. 1.

    Pages and syncs slow down as order volume grows

  2. 2.

    Database load spikes whenever reports run

  3. 3.

    Cloud and data-warehouse costs grow faster than revenue

  4. 4.

    Rate limits throttle syncs at peak hours

Growing order volume and report runs pass through a reworked load path of queues, batching and caching, which takes pressure off the database, spreads work across workers and brings cloud spend back in line.fewer queriesbatched jobsORDER VOLUMEaccounts / channelsREPORT RUNSpeaksLOAD PATHqueue / batch / cacheDATABASEqueries / indexesWORKERSLambda / SQSCLOUD SPENDmeasured
  1. 01ORDER VOLUMEaccounts / channelsLOAD PATHqueue / batch / cache
  2. 02REPORT RUNSpeaksLOAD PATHqueue / batch / cache
  3. 03LOAD PATHqueue / batch / cacheDATABASEqueries / indexesfewer queries
  4. 04LOAD PATHqueue / batch / cacheWORKERSLambda / SQSbatched jobs
  5. 05LOAD PATHqueue / batch / cacheCLOUD SPENDmeasured
Fig. 01Load pathGrowing order volume and report runs pass through a reworked load path of queues, batching and caching, which takes pressure off the database, spreads work across workers and brings cloud spend back in line.Scale NTS

What the engagement covers.

  1. 01

    Load profile

    Where time and money go per request, job and report.

  2. 02

    Database

    Queries, indexes and schema fixed before anyone buys a bigger instance.

  3. 03

    Queues and workers

    Batching, queueing and backoff so peaks stop breaking syncs.

  4. 04

    Rate limits

    Call patterns that stay inside each marketplace's rate limits as volume grows.

  5. 05

    Cost

    Cloud and warehouse spend tied to load, with the waste removed.

How it runs.

  1. P01

    Measure

    Response times, job durations and cost under real load.

  2. P02

    Locate

    The few paths that cause most of the load.

  3. P03

    Fix

    Code, query and infrastructure changes, one at a time.

  4. P04

    Load-test

    Each change checked against the target volume.

  5. P05

    Monitor

    Alerts on the paths that matter, so regressions show early.

What you get.

ItemDeliverableQty

  1. 01Load profile and bottleneck report1
  2. 02Fixes in code, database and infrastructure1
  3. 03Load-test results against the target volume1
  4. 04Monitoring on the critical paths1

Stack08

  • AWS Lambda
  • Amazon SQS
  • PostgreSQL
  • Amazon Aurora
  • BigQuery
  • Node.js
  • TypeScript
  • Amazon SP-API

Related projects.

  1. DL-001Amazon SP-API optimization for an agencyVaso Group · USA01Audit02Stabilize
  2. DL-002FBM and FBA Amazon orders automationHisco Inc. · USA02Stabilize03Build
  3. DL-020Amazon data platform for an advertising agencyName withheld · Germany03Build02Stabilize
  4. DL-043Amazon and Walmart API architecture review for an eCommerce SaaSName withheld · Singapore01Audit02Stabilize
  5. DL-018Architecture audit of a catalogue-mirroring Amazon repricerName withheld · US South01Audit
  6. DL-065Flash-sale inventory protection for a marketplace retailerName withheld · Indonesia01Audit02Stabilize03Build
All case studies

Questions engineers ask us.

Q01Is a bigger server not simpler?

Sometimes, for a while. Usually the cause is a query, a loop or a polling pattern that grows with volume; fixing it costs less than paying for it every month.

Q02Can you work on a live system?

Yes. Changes go in one at a time, measured against the old path, without stopping sales.

Q03Do you work on data pipelines too?

Yes, including exports and warehouse jobs whose cost grows with data. For a ready-made Amazon data layer, see DataDoe, our product.

Q04How do we know it worked?

Every change is measured before and after: response time, job duration, error rate and cost.

Related services.

Ready for many more orders?

Tell us what slows down and at what volume. We reply with where we would look first.

Discuss a project