Merge pull request 'extract: 2026-02-09-oneuptime-hpa-object-metrics-queue-scaling' (#1093) from extract/2026-02-09-oneuptime-hpa-object-metrics-queue-scaling into main

domains/internet-finance/aimd-scaling-solves-variable-load-expensive-compute-coordination-without-prediction.md

@@ -33,6 +33,12 @@ The multiplicative decrease (halving workers on congestion) provides rapid respo
 
 This is an application of proven AIMD theory to a specific system architecture, but the actual performance in the Teleo pipeline context is untested. The claim that AIMD is "perfect for" this setting is theoretical—empirical validation would strengthen confidence from experimental to likely.
 
+
+### Additional Evidence (extend)
+*Source: [[2026-02-09-oneuptime-hpa-object-metrics-queue-scaling]] | Added: 2026-03-16*
+
+KEDA's two-phase scaling (0→1 via event trigger, 1→N via HPA metrics) implements a form of threshold-based scaling without requiring load prediction. The system observes queue state and responds with simple rules: any messages present triggers minimum capacity, then HPA scales linearly with queue depth. This validates that simple observation-based policies work in production without sophisticated prediction models.
+
 ---
 
 Relevant Notes:

domains/internet-finance/time-varying-arrival-rates-require-dynamic-staffing-not-constant-max-workers.md

@@ -32,6 +32,12 @@ Teleo's research processing pipeline exhibits strong non-stationarity: research
 
 Dynamic worker scaling based on current queue depth and estimated arrival rate (with peakedness adjustment) is the theoretically correct solution.
 
+
+### Additional Evidence (extend)
+*Source: [[2026-02-09-oneuptime-hpa-object-metrics-queue-scaling]] | Added: 2026-03-16*
+
+Kubernetes HPA with object metrics demonstrates production implementation of dynamic worker allocation based on queue state. The pattern uses ConfigMaps or custom resources to expose queue depth, which HPA monitors to scale worker replicas. Multi-metric HPA evaluates several metrics simultaneously and scales to whichever requires the most replicas, handling complex workload patterns. KEDA extends this with 70+ built-in scalers for different queue types (RabbitMQ, Kafka, SQS, etc.) and scale-to-zero capability, proving dynamic staffing is production-ready at scale.
+
 ---
 
 Relevant Notes:

entities/internet-finance/futardio.md

@@ -51,6 +51,7 @@ MetaDAO's token launch platform. Implements "unruggable ICOs" — permissionless
 - **2024-06-14** — [[futardio-fund-rug-bounty-program]] passed: Approved $5K USDC funding for RugBounty.xyz platform development to incentivize community recovery from rug pulls
 - **2024-08-28** — MetaDAO proposal to develop futardio as memecoin launchpad with futarchy governance failed. Proposal would have allocated $100k grant over 6 months to development team. Key features: percentage of each new token supply allocated to futarchy DAO, points-to-token conversion within 180 days, revenue distribution to $FUTA holders, immutable deployment on IPFS/Arweave. Proposal rejected by market, suggesting reputational risks outweighed adoption benefits.
 - **2025-11-14** — Solomon launch: $8M raised (12.9x oversubscribed, $102.9M committed) for composable yield-bearing stablecoin
+- **2026-02-03** — Hurupay fundraise launched targeting $3M, closed Feb 7 at $2M (67% of target) in refunding status
 ## Competitive Position
 - **Unique mechanism**: Only launch platform with futarchy-governed accountability and treasury return guarantees
 - **vs pump.fun**: pump.fun is memecoin launch (zero accountability, pure speculation). Futardio is ownership coin launch (futarchy governance, treasury enforcement). Different categories despite both being "launch platforms."

inbox/archive/.extraction-debug/2026-02-09-oneuptime-hpa-object-metrics-queue-scaling.json

@@ -0,0 +1,24 @@
+{
+  "rejected_claims": [
+    {
+      "filename": "queue-depth-based-scaling-outperforms-cpu-based-scaling-for-worker-style-workloads-because-pending-work-is-a-leading-indicator-while-resource-utilization-is-lagging.md",
+      "issues": [
+        "missing_attribution_extractor"
+      ]
+    }
+  ],
+  "validation_stats": {
+    "total": 1,
+    "kept": 0,
+    "fixed": 1,
+    "rejected": 1,
+    "fixes_applied": [
+      "queue-depth-based-scaling-outperforms-cpu-based-scaling-for-worker-style-workloads-because-pending-work-is-a-leading-indicator-while-resource-utilization-is-lagging.md:set_created:2026-03-16"
+    ],
+    "rejections": [
+      "queue-depth-based-scaling-outperforms-cpu-based-scaling-for-worker-style-workloads-because-pending-work-is-a-leading-indicator-while-resource-utilization-is-lagging.md:missing_attribution_extractor"
+    ]
+  },
+  "model": "anthropic/claude-sonnet-4.5",
+  "date": "2026-03-16"
+}

inbox/archive/2026-02-09-oneuptime-hpa-object-metrics-queue-scaling.md

@@ -6,8 +6,12 @@ url: https://oneuptime.com/blog/post/2026-02-09-hpa-object-metrics-queue/view
 date: 2026-02-09
 domain: internet-finance
 format: essay
-status: unprocessed
+status: enrichment
 tags: [pipeline-architecture, kubernetes, autoscaling, queue-based-scaling, KEDA, HPA]
+processed_by: rio
+processed_date: 2026-03-16
+enrichments_applied: ["time-varying-arrival-rates-require-dynamic-staffing-not-constant-max-workers.md", "aimd-scaling-solves-variable-load-expensive-compute-coordination-without-prediction.md"]
+extraction_model: "anthropic/claude-sonnet-4.5"
 ---
 
 # How to Implement HPA with Object Metrics for Queue-Based Scaling
@@ -31,3 +35,10 @@ We don't run Kubernetes, but the patterns are directly transferable to our cron-
 2. Implement scale-to-zero: if no unprocessed sources, don't spawn workers at all (we already do this)
 3. Multi-metric scaling: consider both extract queue depth AND eval queue depth when deciding extraction worker count
 4. The proactive scaling insight is key: our dispatcher should look at queue depth, not just worker availability
+
+
+## Key Facts
+- KEDA (Kubernetes Event Driven Autoscaler) supports 70+ built-in scalers for different event sources
+- KEDA implements scale-to-zero capability: 0→1 replicas via event trigger, 1→N replicas via HPA metrics
+- HPA object metrics allow scaling based on custom Kubernetes objects like ConfigMaps and custom resources
+- Multi-metric HPA evaluates several metrics simultaneously and scales to whichever requires the most replicas