How do you prevent starvation of background memory-compaction jobs while prioritizing critical agent workflows?

Preventing starvation of background memory-compaction jobs means guaranteeing that lower-priority summaries eventually receive enough service, even when urgent agent workflows continuously use most workers. High-priority security and publication steps must keep their deadlines, but background compaction cannot be postponed forever: stale contexts accumulate, old event tails grow, and future critical handoffs may become impossible.

This lesson is about long-term fairness and bounded progress for compaction work, not general task priority assignment or priority inversion.

Beginner-friendly production incident

A LangGraph API-test-generation pipeline has a requirements agent, test generator, security reviewer, and publisher. Celery runs urgent compaction jobs for blocked handoffs and background jobs that refresh summaries before they become urgent.

A burst of security reviews fills the urgent queue. The scheduler always serves critical tasks first, so background summaries wait for hours. Eventually, those neglected workflows have 25,000 extra tokens of uncompressed events; their next security reviews suddenly become urgent too. More urgent jobs arrive, worsening overload.

The failure is a self-reinforcing starvation loop: refusing small amounts of planned maintenance creates larger emergency demand later.

Observe background age → Guarantee a fair service share → Promote aging tasks → Coalesce stale requests → Guard critical deadlines → Verify progress

Step-by-step numerical example

Assume the compaction service completes 20 validated jobs per minute. Critical workflows continuously demand 18 jobs per minute. Background requests arrive at 4 jobs per minute.

1. If strict priority serves only critical requests whenever they exist, background demand can be delayed indefinitely during critical bursts, even if an average of 2 slots/minute are left after serving the stated steady 18/minute. Under perfectly smooth constant rates, background would get those two slots; real bursts, reservations, and priority-queue behavior can eliminate predictable service.
2. A fair-share policy reserves an initial 20% of completed capacity = 4 jobs/minute for background work, leaving up to 16 jobs/minute guaranteed for critical work.
3. But critical demand is 18/minute, so a rigid 20% reservation would create a critical backlog of 2 jobs/minute—unacceptable if critical deadlines are tight.
4. A more suitable policy might reserve 10% = 2 jobs/minute for background, leaving 18/minute to critical work. Background still arrives at 4/minute, so its backlog grows by 2/minute.
5. After 10 minutes, the background backlog adds approximately 20 jobs. To make it stable, reduce background demand through deduplication or schedule an additional 2 jobs/minute of capacity without violating critical latency constraints.
6. For example, if source-revision coalescing removes 50% of background submissions, effective background arrival falls from 4 to 2/minute. Then a 10% guaranteed share can keep up, assuming the average capacity and work mix remain stable.

Key lesson: A fairness percentage is only a starting policy. Sustainable throughput requires *unique arrivals ≤ allocated effective service capacity* for each class over time, with headroom for variability.

Fairness strategies for compaction

1. Minimum background share: Reserve a small bounded slice of actual worker/API completion capacity for older summary maintenance, subject to critical safety deadlines. Measure completions, not only dequeued attempts.
2. Aging: Raise background tasks' effective scheduling weight as wait time increases. Set a maximum permitted age and alert when it is breached.
3. Weighted fair queuing: Divide service opportunities among critical, standard, and background classes; adapt weights to SLA pressure rather than using strict priority alone.
4. Deadline-aware override: Urgent jobs with insufficient time to produce a validated summary should preempt future dispatch choices, but an indefinite stream of critical jobs must trigger capacity or admission interventions.
5. Per-tenant quotas: Limit how much one tenant can consume and ensure small tenants' maintenance receives progress. Preserve tenant-scoped permissions.
6. Coalescing and supersession: When many background jobs cover the same workflow and role, keep the newest needed revision and cancel obsolete unstarted jobs safely. Never discard source events.
7. Work slicing: Break long maintenance compactions into bounded, independently validated units when feasible so they cannot monopolize a worker slot.
8. Backlog recovery windows: Temporarily increase permitted background throughput when urgent load subsides; do not assume quiet windows always exist.
9. Safe expiration: If a background compaction no longer benefits any future consumer, remove the job from demand accounting instead of treating its nonexecution as starvation.
10. Regular audits: Check that low-priority classes achieve real validated completions and do not continuously age into emergencies.

Starvation versus priority inversion

Starvation means a class of legitimate work receives too little service over a prolonged period. It can happen even when every urgent task is scheduled exactly as designed.

Priority inversion means urgent work is blocked by lower-priority work already running, reserved, or holding a resource. A separate urgent worker queue may solve one inversion pattern yet worsen starvation if background capacity is effectively zero.

A fair design must address both, with clear critical-job latency requirements and minimum-progress targets for maintenance.

Designing a bounded-wait policy

Consider three controls:

• Normal target: At least a defined fraction of available service capacity goes to useful background compactions over a rolling interval.
• Aging threshold: A valid background request older than a threshold is promoted to a maintenance-deadline class, unless its source revision has become obsolete.
• Critical guardrail: If urgent p95 latency or deadline-miss rate breaches its service level, temporarily reduce background allocation, but emit an alert and trigger load shedding or capacity review rather than leaving it suppressed indefinitely.

A hard mathematical maximum wait time cannot be guaranteed if capacity is insufficient or the upstream LLM provider is unavailable. State the guarantee's assumptions and define what happens under sustained overload.

LangGraph and Celery design

With LangGraph, schedule background compaction after stable checkpoints and persist the source watermark and next anticipated consumer. Do not block an active node just to refresh a nonurgent summary. Before a node actually needs context, validate the available version or assemble a safe older-summary-plus-event-tail fallback.

With Celery, use distinct queues and worker routing for urgent and background classes or an application-level weighted dispatcher. Broker-specific priority settings do not automatically implement fair queuing. Track *ready, reserved, and executing* tasks, tune prefetch for long jobs, and enforce shared provider request/token quotas. Make tasks idempotent and activate only validated source-revision-compatible summaries.

Avoid holding memory locks across remote model requests. Use immutable candidates and a short version-checked activation, so running background work cannot block urgent readers.

Practical failure drill

Generate a synthetic load where critical jobs arrive continuously for 30 minutes while background jobs accumulate. Validate these properties:

• Critical p95 end-to-end latency stays within the agreed threshold.
• Background jobs with continuing value receive nonzero validated throughput.
• No tenant monopolizes all allowed background service.
• Aged jobs become visible, not silently stranded in worker reservations.
• Obsolete jobs are removed only after lineage and consumer checks.
• No unvalidated summary is activated and no committed source events disappear.
• When upstream quota is too low for all demand, alerts and admission control activate rather than pretending fairness is solved.

Metrics that reveal starvation

Monitor oldest useful background job age, age distribution by class, validated completions per class and tenant, arrival-to-completion ratio, time spent under reserved quotas, promotions caused by aging, newly urgent jobs caused by stale summaries, and missed critical deadlines.

A low mean background wait can hide a small set of jobs waiting indefinitely. Inspect p95/p99 age and maximum age, with appropriate sample counts.

How this differs from earlier curriculum questions

• Q198: General starvation control in multi-agent task scheduling.
• Q237: Efficiency and queue scheduling for compaction work.
• Q239: Backpressure and bounded admission under overload.
• Q240: Which critical compactions deserve priority.
• Q241: Preventing urgent work from being blocked by lower-priority reservations or locks.
• This lesson: Ensuring *background compaction continues to make measurable progress* under continuous critical load through capacity shares, aging, and demand stabilization.

In short

Reserve some useful background progress without violating critical agent deadlines. Combine fair capacity allocation, age-based promotion, deduplication, and explicit overload handling. If the sum of unique incoming work consistently exceeds sustainable capacity, no scheduling policy alone can prevent backlog growth.

Further reading

• Celery: Routing Tasks
• Celery: Optimizing
• LangGraph: Persistence