Design of Global Async Write Switch #41
Description
Abstract
Introduce a global (application-level) write switch to enable or disable asynchronous processing to support zero-downtime write operations.
Why
Enabling Global Async Write Mode allows Actionbase to queue all incoming DML requests. By temporarily pausing the external processors that consume these async queues, we can halt all write operations to the HBase cluster (e.g., during a cluster migration). Even in this state, the Actionbase API remains available, providing a seamless, zero-downtime experience for client applications.
What
- Implement a global async switch that forces all DML operations into async mode.
- Add test suites for the global async switch.
How
We considered two approaches for managing the global async mode state:
| Approach | 👍 Pros | 👎 Cons |
|---|---|---|
| 1. Application Configuration | Simple, intuitive design. No external dependencies. | Requires application redeployment to change settings. |
| 2. External Storage | Online updates without deployment. | Adds external dependencies and requires fallback logic. |
Decision (Proposed)
I prefer Approach 1: Define in application configuration for the following reasons:
- It allows for a faster initial implementation and validation of the global switch logic.
- We can maintain a simple architecture without introducing external dependencies at this stage.
I would like to request a review of this approach. While Option 2 offers better operational flexibility, I believe starting with Option 1 is the most efficient way to move forward for now.