AGENDA

1. 01Thank you - the detailed doc
2. 02Research directions for our collaboration
3. 03DES scaffolding walkthrough
4. 04Questions I have
5. 05Action items & next meeting

THANK YOU FOR THE DETAILED DOC

DIRECTION 1 - MEMORYLESS vs STATEFUL

Right now the orchestrator has “amnesia” - every time a worker polls, it computes the score from scratch and decides which task to hand over.

1. Q1
   Does memoryless scheduling actually treat tenants fairly, or does it drift over time?
2. Q2
   Could we sneak in one tiny counter per tenant (just a number piggybacked on an existing write) and recover most of the benefits of statefulness?

DIRECTION 2 - LEARNING THE WEIGHTS OFFLINE

In the current score formulation, 0.1 and 0.9 are hardcoded weights:

DES already logs every scheduling decision it makes, so we could train an ML model on those historical logs without ever touching production. (This depends on whether you're open to sharing this data - if not, I can synthesize it, but it won't be realistic.)

DIRECTION 3 - PREDICTING TASK DURATION

Currently “wait time” just means how long a task has been sitting in the queue - but if we could predict how long a task will actually take, we could schedule smarter (e.g. priority to short-but-waited jobs).

1. Q1
   Can a small ML model predict task duration from features like tenant, doc size, task type, etc.?Note: a small model could add overhead since the score is recomputed on each worker poll - it needs to be really, really fast.
2. Q2
   If we swap “raw wait time” for “predicted remaining time”, does fairness get better or worse?

WHAT I'VE SETUP SO FAR

A mockup of your DES Task Orchestrator, built end to end so I can study the memoryless fair-scheduling rule under controlled, reproducible conditions.

TWO-VM DEPLOYMENT TOPOLOGY

Deployed on two fresh Ubuntu 22.04 VMs, provisioned by Ansible from my machine (the controller).

THE QUEUE - SQLITE, ATOMIC CLAIMS

A single SQLite file. The atomic new > in_progress flip is one UPDATE ... RETURNING - a statement-level transaction, so concurrent workers can't double-claim.

CREATE TABLE IF NOT EXISTS tasks (
    id           TEXT PRIMARY KEY,
    tenant_id    TEXT NOT NULL,
    task_type    TEXT NOT NULL,
    document     TEXT NOT NULL DEFAULT '',
    status       TEXT NOT NULL,
    created_at   INTEGER NOT NULL,
    assigned_at  INTEGER,
    completed_at INTEGER,
    result       TEXT NOT NULL DEFAULT '',
    error        TEXT NOT NULL DEFAULT ''
);

THE HTTP API (WORKER-FACING)

• GET /health - liveness.
• GET /tasks/available?taskType=X - worker poll; returns a Task JSON, or 204 if none.
• POST /tasks/{id}/complete - body {"result": "..."}; 204 on success.
• POST /tasks/{id}/error - body {"error": "..."}; 204 on success.
• GET /metrics - plain-text fairness + latency snapshot.

THE WORKERS - PYTHON, ZERO DEPS

A bounded-lifetime poll loop (spec 2.4): each KEDA Job processes some work and exits on MAX_TASKS / MAX_RUNTIME / N consecutive empty polls; KEDA respawns Jobs as depth warrants.

QUESTIONS I HAVE

1. Q1
   How should containerization or resource isolation be provisioned - is the current 2-VM setup okay?
2. Q2
   My current implementation uses HTTP as the communication medium. Jayson mentioned it isn't HTTP and that it's event-based - what protocol is used?
3. Q3
   What metrics are you using to measure fairness and latency? P99 per task? Jain's Fairness Index? How long the scheduler's Pick took?

ACTION ITEMS

1. 01
   Replicate your enrichment system + pull key metrics. The DES mockup is built; next I run parameter sweeps (alpha / beta) and capture Jain's index and p99 latencies as a baseline.
2. 02
   Literature study. Still revising my literature review. The current list focuses on batch LLM inferencing; I'm broadening it to include more on scheduling and distributed computing.

NEXT MEETING