fulfillmenttools
API documentationIncident ManagementFeedback
Developer Docs
Developer Docs
  • Developer docs
  • Getting Started
    • Quickstart
    • Integration tutorial
      • Adding facilities
      • Adding listings to facilities
      • Configuring stocks
      • Carrier configuration
      • Placing orders
      • Checkout options
      • Distributed Order Management System (Routing)
      • Local fulfillment configuration
    • Free trial
  • Technical Basics
    • Access to fulfillmenttools
    • Feature status
    • Available regions
    • Backup policies
  • Connecting to fulfillmenttools
    • Client SDKs
    • commercetools connect
    • OpenID connect
      • Configure Microsoft Entra ID / Azure Active Directory
      • Configure Keycloak
  • API
    • Core concepts
      • Authentication & authorization
      • API Versioning & lifecycle
      • Assign user to jobs
      • Localization
      • Resource timestamps
      • Custom attributes
      • Article attributes
      • Recordable attributes
      • Data update guarantees
      • Rate limits & scaling
      • Retries
      • Performance on test vs. production systems
      • Load testing
    • API calls
      • Postman
      • cURL
      • GraphQL Explorer
    • GraphQL API
    • RESTful API
      • Pagination interface
      • RapiDoc
      • OpenAPI 3.0 Spec
    • Eventing
      • Structure of an event
      • Available events
        • Event flows
      • Eventing example
      • Event export
  • Integration Guides
    • Address formats for specific carriers
    • Basics
      • Article categories
      • Audits
      • Custom services & bundled line items
      • Facilities
      • Facility groups
      • GDPR configuration
      • Listings
      • Orders
        • Order types
        • Order status
      • Remote configuration
      • Receipts
      • Search
      • Subscribe to events
      • Sticker
      • Stocks
      • Storage locations
      • Tags
      • Users
    • Channel inventory
    • Facility discounts
    • Inbound process
    • Outbound stocks
    • Purchase order
    • Receipt
    • Routing strategy
    • Show sticker to clients
    • Stow jobs
  • More Integration Guides
    • Carrier management
      • Introduction to carrier configuration
      • Required data when operating carriers
      • Adding & connecting carriers to facilities
      • Custom carrier
    • Configurations for order fulfillment
      • Picking configuration
      • Packing configuration
      • Handover configuration
      • Printing and document configuration
      • Packing container types
      • Parcel tag configuration
      • Headless order fulfillment
      • Short-pick reasons
      • External documents in order fulfillment
      • Service jobs
      • Load units
      • Running sequence
    • DOMS - distributed order management system (routing)
    • External actions
    • Interfacility transfer
    • Notifications
    • Availability & promising
    • Returns
Powered by GitBook
On this page
  • Test system setup (PRE)
  • Production system setup (PRD)
Edit on GitHub
  1. API
  2. Core concepts

Performance on test vs. production systems

Last updated 3 months ago

Test system setup (PRE)

PRE systems are only suitable for functional tests, e.g., testing individual use cases of the integration. Fulfillmenttools generally does not allow load tests on these PRE environments (please see for details). The fulfillmenttools platform scales to zero if no API traffic is present for some time. Scaling to zero applies to both the REST API and the GraphQL API. In this state, zero instances are ready to serve API traffic. The state of the platform is now cold.

For some cases, fulfillmenttools can temporarily manually generate a production-like environment on PRE (scaling properties, the configuration of database connections, etc.). Please use our to contact us.

Cold starts

On a cold system, the whole platform scales to zero. On the first API request (e.g., creating an Order via the REST API), the platform performs a cold start and starts the services required to serve the API. The fulfillmenttools platform is warm, and the API responds quickly to requests.

The cold start will block the first request until the API is ready to serve traffic. Starting the API gateway instances takes up to 30 seconds to complete. Since the fulfillmenttools platform is a distributed system and uses asynchronous events to communicate within the platform, this event distribution is also affected by cold starts. Nevertheless, if there is constant traffic on a tenant, cold starts are only encountered when resources are scaled up.

Scaling

Generally, test systems scale similarly to production systems once in a warm state. The fulfillmenttools platform scales based on parallel concurrent requests and resource usage (CPU, memory). See for details. Nevertheless, the max scaling configuration is different from production systems.

Production system setup (PRD)

The API gateways (HTTP and GraphQL) are always warm on production systems. Therefore, no cold starts are expected on the first request. These measures reduce API latency, and events are delivered promptly.

Typically, a production system has some activity (orders coming in, checkout options requests, pick jobs being picked, etc.). These activities also keep our asynchronous event processing services warm.

The production environment configuration ensures the elasticity and scalability of both the compute resources of our backend and database systems.

load testing
service portal
Scaling Behavior Under Load