[Feature Request]: Seamless GAS-Level Load Balancing and Inter-Node Traffic Distribution

[w0l4i]

Background & Context
Building on the discussions regarding the Google Apps Script (GAS) architecture in #462, I would like to propose a new architectural approach to optimize traffic handling and bypass strict single-account quota limitations.

The Idea
Implement a distributed, seamless load balancer directly at the GAS level. If GAS deployments on different Google accounts can communicate with each other efficiently, we can create a network of GAS nodes that share the workload.

Instead of a client relying solely on one GAS URL, the architecture would allow for inter-GAS communication:

Inter-GAS Routing: Deployment A (on Account 1) receives traffic from the client. Instead of processing the entire payload itself, it can request or offload specific tasks (e.g., DNS routing, lightweight requests) to Deployment B (on Account 2).

Traffic Spreading: GAS nodes can talk to each other to spread the incoming client traffic, effectively balancing the bandwidth.

Expected Benefits

Quota Optimization: By distributing the UrlFetchApp and execution time across multiple Google accounts, we can dramatically reduce the chance of burning through a single account's daily quota.

Lower Latency & Faster Load Times: Dynamic balancing could route traffic through the most responsive GAS nodes at any given time.

Higher Bandwidth: Aggregating the capabilities of multiple accounts provides a higher overall throughput for the end client.

Technical Considerations / Open Questions

Does a GAS-to-GAS UrlFetchApp call heavily impact the quotas of both the sender and the receiver, or is the overhead low enough to justify the extra hop?

How can we manage a secure, dynamic registry of active GAS node endpoints for them to communicate with each other?

This could introduce a powerful new layer of balancing to the architecture. I'd love to hear the developers' thoughts on whether this inter-script communication is feasible within the current Rust/GAS design! 💡

@therealaleph @claude @euvel

[Plangto]

Background & Context Building on the discussions regarding the Google Apps Script (GAS) architecture in #462, I would like to propose a new architectural approach to optimize traffic handling and bypass strict single-account quota limitations.

The Idea Implement a distributed, seamless load balancer directly at the GAS level. If GAS deployments on different Google accounts can communicate with each other efficiently, we can create a network of GAS nodes that share the workload.

Instead of a client relying solely on one GAS URL, the architecture would allow for inter-GAS communication:

Inter-GAS Routing: Deployment A (on Account 1) receives traffic from the client. Instead of processing the entire payload itself, it can request or offload specific tasks (e.g., DNS routing, lightweight requests) to Deployment B (on Account 2).

Traffic Spreading: GAS nodes can talk to each other to spread the incoming client traffic, effectively balancing the bandwidth.

Expected Benefits

Quota Optimization: By distributing the UrlFetchApp and execution time across multiple Google accounts, we can dramatically reduce the chance of burning through a single account's daily quota.

Lower Latency & Faster Load Times: Dynamic balancing could route traffic through the most responsive GAS nodes at any given time.

Higher Bandwidth: Aggregating the capabilities of multiple accounts provides a higher overall throughput for the end client.

Technical Considerations / Open Questions

Does a GAS-to-GAS UrlFetchApp call heavily impact the quotas of both the sender and the receiver, or is the overhead low enough to justify the extra hop?

How can we manage a secure, dynamic registry of active GAS node endpoints for them to communicate with each other?

This could introduce a powerful new layer of balancing to the architecture. I'd love to hear the developers' thoughts on whether this inter-script communication is feasible within the current Rust/GAS design! 💡

@therealaleph @claude @euvel

Awesome idea

[therealaleph]

@w0l4i — substantive RFC, thank you. Let me think through what's tractable + what isn't:

Restating your proposal in concrete terms:

You're proposing GAS-level load balancing where:

1. Multiple Apps Script deployments coordinate via shared state (Sheets / KV / Cache)
2. A "controller" deployment routes incoming requests to the least-loaded "worker" deployment
3. Workers can pass traffic between each other if one is quota-exhausted
4. mhrv-rs client sees a single endpoint; the GAS layer handles distribution

What's good about it:

• Quota smoothing — instead of mhrv-rs's client-side rotation hitting individual deployment quotas, the GAS layer can dynamically reroute around overloaded ones
• Single endpoint for client — simpler client config (only one deployment ID needed)
• Inter-node traffic distribution — could enable creative patterns like "worker A's UrlFetchApp is at quota, so route through worker B's UrlFetchApp"

What I think won't work:

• UrlFetchApp quota cannot be shared between accounts. Each Google account has its own 20K/day quota. Worker B fetching on behalf of Worker A's request still consumes Worker B's quota — there's no "merged" quota. So inter-node routing only matters when Worker A is at quota AND Worker B isn't, which is a fraction of failure cases.

• GAS-to-GAS routing has latency cost. Worker A receiving a request → checking shared state (50-200ms Sheets/Cache read) → forwarding to Worker B (1 UrlFetchApp call, 250-500ms) → Worker B receiving → fetching upstream (250-500ms) → returning back through Worker A. That's 2-3x the latency of direct routing for the same request.

• Synchronization/consistency is hard with GAS's single-execution-thread model. Sheets reads aren't atomic. Cache TTLs are eventual-consistent. A "least-loaded worker" calculation is racy across concurrent batch arrivals.

• Active-probing surface grows. Each shared-state access (Sheets / Cache / cross-deployment URL) is a fingerprint that DPI can identify. Currently mhrv-rs traffic looks like normal Apps Script POST. Cross-deployment chatter doesn't.

What's tractable from your proposal (subset that ships):

Per-deployment health metrics in shared state: Each deployment writes its own (timestamp, recent_success_rate, recent_quota_estimate) to a shared CacheService entry every minute. Read-only. The mhrv-rs client (which already does deployment rotation) reads this metadata and weights its routing toward healthier deployments. No GAS-to-GAS routing — just deployment-self-reporting that the client uses to rotate smarter.

This avoids the quota-share + latency-cost + consistency-cost concerns above while still capturing your "smarter rotation than round-robin" intuition. Roughly:

// In Code.gs / CodeFull.gs:
function _heartbeat() {
  var stats = {
    success_rate_5m: _recentSuccessRate(),
    quota_estimate: _quotaUsedThisDay(),
    last_seen: Date.now()
  };
  CacheService.getScriptCache().put(
    'heartbeat:' + ScriptApp.getScriptId().substring(0, 8),
    JSON.stringify(stats),
    300 /* 5 min TTL */
  );
}

// In mhrv-rs client:
// Periodically fetch heartbeat from each deployment, weight rotation
// by 1.0 - quota_estimate * 0.5 - failure_rate

This is client-side intelligent rotation backed by GAS-side self-reporting. Achievable in ~1-2 weeks. Aligns with the per-deployment quota counter feature already on the v1.9.x roadmap (#454).

Architectural alternative for true load balancing — xmux (v1.10.0):

The v1.10.0 xmux design accomplishes a stronger version of what you want:

• Single client request → split across multiple deployments at byte-range level
• If one deployment is throttled, the others carry the response slack
• No GAS-to-GAS coordination — coordination is at the client layer where it's simple

Trade-off: xmux requires bigger client-side changes (reordering buffer, byte-range chunking) but is more architecturally clean than GAS-side load balancing.

My recommendation:

1. v1.9.x: ship the heartbeat-based smarter-rotation feature (subset of your proposal). Quick win, low risk, real benefit for multi-deployment users.

2. v1.10.0: ship xmux for the deeper architectural fix.

3. Skip the GAS-to-GAS routing piece — the latency + complexity costs outweigh the benefits given Apps Script's per-account quota model.

Tagging you on the v1.10.0 xmux design issue when filed (~2-3 weeks). The heartbeat feature can land sooner — happy to design + implement that one in collaboration if you have suggestions for the metrics shape.

This issue stays open as the canonical tracking for the v1.9.x heartbeat-rotation feature. Will close when both ship.

Thanks for keeping the architectural pressure on the project — your RFCs are responsible for several of the v1.8.x/v1.9.0 wins (DNS architecture from #449, edge cache via #491→#494, decoy taxonomy refinement from #404). Keep them coming.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[euvel]

@therealaleph I've been thinking about the heartbeat-based rotation you mentioned. One thing that stood out: health data is written to CacheService every 5 minutes, but how does the Rust client actually read it without burning quota on dedicated health-check requests?

What if every relay response simply included the cached health data? The deployment already writes to CacheService. Adding a read in _json() costs ~10ms and ~100 bytes:

function _json(obj) {
  var cache = CacheService.getScriptCache();
  var health = cache.get('heartbeat:' + ScriptApp.getScriptId().substring(0, 8));
  if (health) obj._h = JSON.parse(health);
  return ContentService.createTextOutput(JSON.stringify(obj))
    .setMimeType(ContentService.MimeType.JSON);
}

The client accumulates _h from normal responses over time and weights rotation accordingly. No extra requests, no new endpoints, no change to traffic fingerprint. Low-traffic deployments still get their health refreshed by the trigger. The response enrichment pattern is the same one already used for cached: true/false in the spreadsheet cache.

Not sure if this is the right approach or if there's a cleaner way to handle the read path, but figured it was worth mentioning.