Beyond the Sync Chain: Avoiding the Distributed Monolith in OutSystems ODC

Introduction The transition to OutSystems Developer Cloud (ODC) is more than just a platform upgrade; it’s a paradigm shift. In O11, we were used to “Strong References” where modules were tightly knit. In the cloud-native world of ODC, apps are independent citizens. However, many developers fall into the trap of the Distributed Monolith — an architecture where services are separated but so tightly coupled via synchronous calls that they fail as a single unit.

The “Wait-and-Die” Syndrome

In a synchronous chain, App A calls App B, which calls App C. If App C experiences a 2-second latency, App A’s worker threads start to hang. This is the “silent killer” of cloud uptime. In ODC, every Service Action is a network hop. Chaining them doesn’t just slow things down; it creates a fragile web where one slow service takes down the entire ecosystem.

Three Ways to Communicate in ODC

1. Service Actions (Synchronous)

These are your standard REST-based calls wrapped in OutSystems logic.

• Best For: When the user cannot proceed without the result.
• Anti-Pattern: Using them to “sync” data between two apps. If you find yourself calling CreateOrUpdateCustomer in another app via a Sync Service Action, stop. You’re building a monolith.

2. Async Service Actions

By selecting the “Async” property, you tell ODC to handle the request via an internal queue.

• The Win: The calling app gets an immediate “Accepted” response, allowing the user to continue.
• Pro Tip: Use these for side effects like sending emails or triggering external integrations that don’t need to return data to the current screen.

3. ODC Events (The Architect’s Favorite)

ODC Events implement a true Pub/Sub (Publish/Subscribe) model.

• Why it works: When a user places an order, the “Order App” simply fires an OrderPlaced event. It doesn't care who is listening.
• Independence: The “Inventory App” and “Shipping App” subscribe to that event. If the Shipping App is down for maintenance, the Order App doesn’t care. The message stays in the router until Shipping is back online.

Architecture Tip: The Local Replica Pattern

To truly decouple, stop “fetching” data from other apps. Instead:

1. Subscribe to events from the source app (e.g., ProductUpdated).
2. Store a “Read Model” (a local cache entity) of that data in your own app.
3. Read from your local entity.

Your app is now lightning fast and 100% resilient to other apps’ downtime.

Conclusion

Don’t bring O11 habits into a cloud-native world. Use Sync for immediate needs, Async for heavy lifting, and Events for everything else. Your uptime (and your users) will thank you.