OMS Projects: 3 key ways to reduce risk and ensure success

Learn more

5 Scalability Metrics That Matter for Order Management Systems
(Every Second)

Hint: Think beyond order volume when choosing your solution.

What can your OMS do?

By Nicola Kinsella

Nov 16, 2024

What’s one of the scariest things when you buy new software? Especially transactional software as a high-growth or enterprise business?

Knowing if it can scale. How can you have confidence it won’t crash when it counts the most?

Sure, it looked good in the demo—processing one order at a time. But how will it hold up when it’s under load? Especially if it’s a distributed order management system that’s responsible for showing accurate item availability and processing orders.

For example, during peak sale events. Imagine your customers having to queue due to latency, or worse, part of your commerce tech stack goes down.

That’s a very bad customer experience.

Considering the right scalability metrics and asking the right questions ahead of time will give you confidence your system has your back. Not just in the first six months but as your business grows year after year, and inevitably your volumes.

5 Scalability Metrics to Ask About

1. Orders per second

What it is: The number of orders the order management system (OMS) can process (receive from your commerce platform and/or other digital channels) per second.

Why it’s important:  During peak sale events, you want to make sure you don’t lose orders or keep customers waiting.

Questions to Ask

  • How many orders can you process per second? Per minute? Per day?
    • What is the average and what are the peak order volumes processed? This is important because order volumes may start low and increase during the day and taper off.

Real-World Examples:

  • One large Fluent Order Management customer processes 284K orders per day (that’s an average of 11,833 orders per hour, 197 orders per minute, 3.3 per second)
  • One Fluent Order Management customer has processed 181 orders per second
  • And another customer, with higher lines per order, the more interesting stat is 302K items sold per second

2. Order promises per second

What it is: The number of delivery and pickup promises your OMS can make at the same time. The promises include checking item availability and running sourcing logic before the order is placed. Delivery and pickup promises can be shown on the Product Listing Page (PLP) for multiple items, Product Details Page (PDP) for a single item, and during checkout to show delivery and pickup availability across the entire cart, including different fulfillment options by line item.

Why it’s important: Showing customers accurate pickup and delivery availability earlier in the buying journey helps increase conversion rates, and reduces canceled orders.

Questions to Ask

  • How many order promises can you make per second? Per minute? Per day?
    • What are the peak volumes for order promises?
  • Can you provide pickup and/or delivery promises for multiple items on the PLP?
  • Are order promises made based on real-time sourcing or cached data?

Real-World Examples:

  • Fluent Order Management makes over 7.6 million delivery and pickup promises per day on average (that’s 88 promises per second)
  • For one customer during a sale event, Fluent Order Management made 1,969 delivery and pickup promises per second

3. Overall API call volumes

What it is: The number of API calls a solution can process per second, minute, hour, day, and month).

Why it’s important: This provides an indication of overall scalability, as in a modern, cloud-native solution the volume of API calls for order promises and inventory updates will far exceed the volume of API calls for orders.

Questions to Ask

  • How many API calls can you process per second? Per minute? Per day?
    • What’s the peak API calls processed per second?

Real-World Examples:

  • Fluent Order Management processes over 100 billion API calls per month on average (that’s 3.3 billion API calls per day, 2.3 million API calls per minute, 38.3 thousand calls per second)
  • For a single customer during peak sales, Fluent Order Management reached 9+ million API calls per day

4. API response times

What it is: There are two types of API response times to look at:

  • Average API response time: The average time for an API to respond to a request across all types of requests, simple and complex.
  • API response time for complex requests: How long it takes to respond to a complex request that includes, say, pickup and delivery availability based on live sourcing decisions (real-time, not using cached data).

Why it’s important:  Faster response times mean an OMS can process more requests per second, minute, and hour. Longer latency means slower page loads which negatively impacts customer experience and conversions.

Questions to Ask

  • What is the average API response time?
  • Can you provide some examples of response times for complex requests?

Real-World Examples:

  • Fluent Order Management has a 20ms average API response (combining simple and complex requests)
    • Response times for simple API requests range between 5-10ms
    • Response times for complex API requests can be 500ms for things like including 24 delivery and pickup promises on the PLP

5. Inventory position updates processed per second

What it is: The number of inventory availability updates that an OMS is able to ingest and process from other systems, such as your ERP, or sales transactions from your Point of Sale (POS) system.

Why it’s important:

Two reasons:

  • Inventory accuracy: The faster your OMS can process inventory position updates, the more accurate your inventory availability will be on digital channels. Without accurate inventory, you risk overselling and having to cancel orders, which leads to disappointed customers. It also increases contact center calls and costs.
  • Many legacy systems can send delta feeds: If your ERP can only send all inventory positions as a large batch file, rather than just the changed inventory positions, it’s important that your OMS can quickly and intelligently process this data so that changed records can be updated as quickly as possible.

Questions to Ask

  • How many inventory position updates can you process per second?
    • What are the peak volumes of inventory position updates processed per second? Per minute? Per day?

Real-World Examples:

  • One customer sends Fluent Order Management 180 million inventory position updates a day (that’s 7.5 million inventory updates per hour, 125K per minute, and 2K per second)
  • The peak volume (so far) processed by Fluent Order Management was 369,271 inventory position updates in a minute (that’s 6,155 inventory position updates per second)

So what’s the moral of the story?

Orders per second isn’t the only metric that counts

If you’re evaluating order management systems, and only asking about ‘orders per second’, you’re probably missing some critical data. Especially when understanding how well a solution can scale to meet your growth goals. Dig deeper. Ask about these metrics:

  1. How many orders can you process per second? Per minute? Per day?
    • What are the peak order volumes processed?
  2. How many order promises can you make per second? Per minute? Per day?
    • What are the peak volumes for order promises?
  3. Can you provide pickup and/or delivery promises for multiple items on the PLP?
  4. Are order promises made based on real-time sourcing or cached data?
  5. How many API calls can you process per second? Per minute? Per day?
    • What are the peak API calls per second?
  6. What is the average API response time?
  7. Can you provide some examples of response times for complex requests?
  8. How many inventory position updates can you process per second?
    • What are the peak volumes of inventory position updates processed per second? Per minute? Per day?

To learn more about how Fluent Order Management can help you achieve your digital commerce growth goals, contact us today.

This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.