I Tested Integration Performance Across Local and Remote Systems — Here’s What I Learned

Introduction

When building integrations, performance often feels great during development.

Everything runs locally, responses are instant, and flows execute in milliseconds.

But once systems move across networks — databases, APIs, cloud infrastructure — performance can change dramatically.

I recently ran a performance experiment while building an Order API integration to measure how infrastructure affects response time.

The results were eye-opening.

The Integration I Built

The system handles core order processing operations including:

• Inventory checks • Order retrieval • Reservation flows • Asynchronous order processing

These flows simulate the type of operations you see in real commerce systems.

To understand performance differences, I tested the integration in three infrastructure scenarios:

1️⃣ Local application + Local database 2️⃣ Local application + Remote database 3️⃣ Remote application + Remote database

Scenario 1 — Everything Running Locally

Application: Local Database: Local (Docker)

Results were extremely fast and consistent.

All requests completed in under 300 milliseconds.

However, I noticed something interesting.

The asynchronous flow for creating a new oder completed quickly, but for the system to process and update the order status sometimes appeared slightly delayed compared to when systems were remote.

This is likely due to how async jobs and local resources schedule execution.

Still, overall performance was extremely fast.

Scenario 2 — Local Application + Remote Database

Application: Local Database: Remote

Now the integration had to cross a network boundary to communicate with the database.

The difference was dramatic.

Inventory Check

First run: 5.48 seconds Second run (different network): 9.86 seconds

Retrieve Order

First run: 4.08 seconds Second run: 4.08 seconds

Async Order Flow

Execution time: 9.86 seconds

This shows how network latency and infrastructure distance dominate performance.

Scenario 3 — Remote Application + Remote Database

Application: Remote Database: Remote

This scenario simulates something closer to a real production deployment.

Results varied due to testing on different networks to see performance.

Retrieve Order by ID

First network: 4.1 seconds

Second network: 47.66 seconds

Yes — 47 seconds.

Async Flow

Execution time: 3.87 seconds

Inventory Check

First run: 1.84 seconds

Second run: 10.81 seconds

The variability here highlights an important lesson.

Integration performance is not just about system design, but also about network reliability and infrastructure stability.

What This Experiment Reveals

Many developers assume performance is mostly determined by:

• code efficiency • logic complexity • transformation operations

But in integration systems, performance is often dominated by:

• network latency • infrastructure distance • external service calls • database location • network stability

In other words:

The slowest part of an integration is usually the network, not the code.

Integration Design Lessons

From this experiment, a few design principles become clear.

1️⃣ Minimize Cross-Network Calls

Every remote call introduces latency.

2️⃣ Prefer Asynchronous Processing

Async workflows prevent long blocking operations.

3️⃣ Use Event-Driven Architectures

Systems communicating via events reduce synchronous dependencies.

4️⃣ Design Around System Boundaries

Understanding where services run is critical for performance.

Final Thought

When integrations are tested locally, they often feel incredibly fast.

But once databases, APIs, and services move across networks, the real performance characteristics emerge.

Good integration design is not just about building flows.

It’s about understanding systems, infrastructure, and network behavior.

If you’re working with APIs, integrations, or distributed systems, performance testing across environments is essential.

Because in enterprise integrations:

Architecture decisions matter far more than code speed.