The Integration Maestro Rules
I'm Artemii Karkusha, an integration architect. I've spent years building and debugging integrations between ERPs, PIMs, eCommerce platforms, and everything in between.
These rules are patterns I've seen repeatedly — in ERP pricing flows that crash under load, in webhook systems that duplicate orders, in "simple" API calls that take down production. They're not theoretical. They're extracted from real failures.
I named them because unnamed patterns get ignored. When something has a name, you can reference it, debate it, and — most importantly — remember it when you're designing systems at 2 AM before a deadline.
How to Use These Rules
- →Rules have names so they can be referenced. Use them in architecture discussions, code reviews, and design documents. Say "this violates the Latency Compounding Law" instead of explaining from scratch.
- →Violating a rule should be conscious. Sometimes you break a rule for good reasons — business constraints, legacy systems, time pressure. That's fine. Just know you're doing it.
- →Disagreement is expected. These rules reflect my experience. Your context may differ. If you think a rule is wrong, you're probably right for your situation.
Quick Reference
The Distributed Reality Rule
Every integration is a distributed system — whether you like it or not.
The Latency Compounding Law
Integration latency compounds — it never adds.
The Idempotency Mandate
If it can retry, it must be idempotent.
The ERP Bottleneck Principle
ERPs are systems of record — not systems of interaction.
The Real-Time Illusion
"Real-time" is a business requirement, not a technical one.
The Aggregation First Rule
Integrations should aggregate data before serving it.
The Failure Surface Rule
Every integration call increases the failure surface.
The Retry Storm Effect
Unbounded retries turn small failures into outages.
The Data Gravity Rule
Data should be consumed close to where it changes.
The Ownership Boundary Rule
Every integration must have a single owner of truth.
The Distributed Reality Rule
Every integration is a distributed system — whether you like it or not.
Meaning
If two systems communicate over a network, you inherit the realities of distributed systems. That includes latency, partial failure, retries, and inconsistent state. Treating integrations as "simple API calls" is the fastest way to ship something that only works in demos.
Use this rule when:
- •Someone proposes "simple REST calls" between systems
- •Retries and timeouts are treated as edge cases
- •Synchronous communication is assumed to be safe by default
Short version
If it crosses a network, it's a distributed system. Design it like one — or debug it at 3 AM.
The Latency Compounding Law
Integration latency compounds — it never adds.
Meaning
Multiple "fast" integration calls do not behave like a single slow one. Network overhead, serialization, queuing, cold starts, and cache misses multiply the cost of every additional call. This is why systems with individually fast APIs still feel slow in production.
Use this rule when:
- •Pages load slowly despite "fast APIs"
- •Microservices or backend calls grow unchecked
- •ERP or third-party calls are chained synchronously
Short version
One slow API is a bug. Ten "fast" APIs is an outage.
The Idempotency Mandate
If it can retry, it must be idempotent.
Meaning
Retries are not optional in real systems. Networks fail, clients repeat requests, and message delivery is not guaranteed to be exactly once. If repeating a request can create duplicates, charge twice, or corrupt state, the integration is unsafe by design.
Use this rule when:
- •Designing webhooks
- •Implementing payment or order flows
- •Replaying events
- •Building queue consumers
Short version
Retries are guaranteed. Safety is optional — unless you design for it.
The ERP Bottleneck Principle
ERPs are systems of record — not systems of interaction.
Meaning
ERP systems are typically slow, stateful, and expensive to scale. Placing them directly in the user request path creates a hard dependency between UX performance and ERP availability. This turns ERP latency into customer-visible downtime.
Use this rule when:
- •Real-time ERP pricing is requested
- •Live stock checks are pulled directly from ERP
- •User flows block on ERP availability
Short version
If your UX depends on ERP response time, your UX will eventually depend on ERP downtime.
The Real-Time Illusion
"Real-time" is a business requirement, not a technical one.
Meaning
Most demands for real-time integration actually mean near-real-time, eventually consistent, or simply "feels fast." Enforcing strict real-time behavior increases coupling, reduces resilience, and often harms performance without delivering real business value.
Use this rule when:
- •Stakeholders demand instant synchronization
- •Asynchronous patterns are rejected prematurely
- •Event-driven approaches are dismissed
Short version
Real-time feels good in demos. Async survives Black Friday.
The Aggregation First Rule
Integrations should aggregate data before serving it.
Meaning
Consumers should request already-assembled data, not orchestrate multiple backend calls. Forcing frontends or clients to stitch data across systems increases latency, coupling, and the overall failure surface of the architecture.
Use this rule when:
- •Frontends make multiple backend calls per request
- •Mobile apps call ERPs directly
- •GraphQL vs REST debates arise
Short version
The consumer should request data — not assemble it.
The Failure Surface Rule
Every integration call increases the failure surface.
Meaning
Each external dependency adds new ways for a request to fail: timeouts, retries, partial outages, and cascading errors. Architectures should aim to reduce call count, not maximize service reuse through synchronous chains.
Use this rule when:
- •Adding "just one more API call"
- •Designing synchronous workflows
- •Reviewing service-to-service call chains
Short version
Every extra call is a new way to fail.
The Retry Storm Effect
Unbounded retries turn small failures into outages.
Meaning
Retries without limits, backoff, or circuit breakers amplify load instead of resolving failures. Under stress, they overwhelm downstream systems and trigger cascading outages across otherwise healthy components.
Use this rule when:
- •Queues start backing up
- •Systems degrade rapidly under load
- •Failures propagate unexpectedly
Short version
Retries don't heal systems. Limits do.
Related deep dives
The Data Gravity Rule
Data should be consumed close to where it changes.
Meaning
Repeatedly pulling data from a source system increases latency, wastes capacity, and introduces inconsistency. Event-driven propagation combined with caching is more reliable and scalable than constant polling.
Use this rule when:
- •Polling ERP systems for changes
- •Syncing large datasets
- •Designing product or pricing synchronization
Short version
Move events — not databases.
The Ownership Boundary Rule
Every integration must have a single owner of truth.
Meaning
When multiple systems believe they own the same data, conflicts are inevitable. Bidirectional synchronization without clear ownership leads to overwrites, inconsistency, and silent data corruption.
Use this rule when:
- •Bidirectional sync is proposed
- •Master data ownership is unclear
- •Sync conflicts appear in production
Short version
If everyone owns the data, no one does.
Related deep dives
Reference & Share
Link Directly
Each rule has a permanent anchor. Use it in docs, PRs, or discussions.
integration-maestro.com/rules#latency-compounding-lawDisagreement Welcome
These rules reflect my experience. If your context demands a different approach, that's not wrong — it's architecture. Feel free to challenge any of them.
You're free to reference these rules in architecture discussions, design documents, and technical debates.
Need help applying these rules?
I offer architecture reviews, integration audits, and consulting for teams building ERP, eCommerce, and high-load integrations.
Let's talkArtemii Karkusha is an integration architect focused on ERP, eCommerce, API design, and high-load system integrations. This site documents real production failures and architectural decisions.