digiRunner's transaction stability in the event of a lost DB connection

[Eddie-Las]

Hi everyone,

I'm exploring digiRunner’s resilience and runtime behavior under database failures, and I’d like to confirm how the system reacts under different DB-related conditions.

Here are the scenarios I'm particularly interested in:

• Will digiRunner continue processing API traffic normally during a short-term DB outage?

• What happens if the disconnection lasts longer—does the behavior change?

• How does digiRunner handle scenarios where the database enters read-only mode?

• Would any of these situations immediately impact API availability or transaction processing?

Overall, I’d like to understand whether these DB issues will immediately impact API availability, or if digiRunner is designed to remain operational under partial failures.

Any technical insights, real-world experience, or official guidance would be greatly appreciated — thanks in advance! 🙏

[TPIsoftwareOSPO]

Hi!
Thanks for bringing this up — it’s a great question and an important topic when it comes to digiRunner’s fault tolerance and service continuity.
Here’s a clear breakdown of how digiRunner behaves under different database connection scenarios:

---

✅ 1. Short-Term DB Connection Instability (a few seconds of network jitter)

Impact: Almost none.

digiRunner uses an in-memory data cache to ensure fast and stable API response times.
This means that during brief DB latency or momentary disconnections:

• APIs continue to function normally
• Cached data can still be read instantly
• Traffic spikes or short unstable periods won’t block requests

Limitation:
If the cache needs to refresh and the database is unavailable at that moment, digiRunner will not be able to fetch updated data.
Only then will you start seeing issues with data correctness or service continuity.

---

✅ 2. Long-Term DB Disconnection (while transactions continue)

If your requirement is:

“Even if the database is down for an extended time, API traffic must continue uninterrupted.”

Then you will need digiRunner’s In-Memory Gateway Architecture.

Key advantages:

• Eliminates single points of failure
• APIs keep running entirely from memory
• Supports HA, DR, blue/green deployment, and zero-downtime upgrades
• Even if the primary DB is unavailable, the gateway continues serving requests

⚠️ Note:
This dual-centered in-memory gateway architecture is an Enterprise Edition feature and usually requires assistance from TPIsoftware’s professional services team.

The Open Source edition also includes an in-memory gateway, but its resilience is not equivalent to the Enterprise HA design.

---

✅ 3. DB is Connected but in Read-Only Mode

This situation produces two different behaviors:

(1) API Services

API operations often continue working because:

• Required data may already be cached
• Or the APIs are performing read-only operations

(2) Admin Console (AC)

The Admin Console will be affected, because nearly all AC operations require DB write actions, such as:

• Creating/modifying users, roles, organizations
• Registering or updating APIs
• Deploying API Composer flows
• Changing system settings
• Writing audit logs

If the DB is read-only:

• AC login or operations may fail
• Management tasks cannot be performed
• Monitoring dashboards will show DB issues

---

📌 Summary

digiRunner provides different levels of protection depending on the scenario:

• Short-term DB instability → Minimal impact due to in-memory caching
• Long-term DB failure → Requires Enterprise Edition’s In-Memory Gateway Architecture
• DB in read-only mode → APIs mostly unaffected, AC operations restricted

Hope this breakdown helps!
If you have more questions about resilience, HA design, or deployment strategy, feel free to continue the discussion — happy to help!