{"id":48531616,"url":"https://github.com/fullzer4/adaptive-priority-queue-redis-streams-poc","last_synced_at":"2026-04-08T00:02:06.877Z","repository":{"id":347566435,"uuid":"1175639519","full_name":"fullzer4/adaptive-priority-queue-redis-streams-poc","owner":"fullzer4","description":null,"archived":false,"fork":false,"pushed_at":"2026-03-08T02:11:32.000Z","size":2,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-03-28T16:09:01.193Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/fullzer4.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-03-08T01:06:17.000Z","updated_at":"2026-03-08T02:11:36.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/fullzer4/adaptive-priority-queue-redis-streams-poc","commit_stats":null,"previous_names":["fullzer4/adaptive-priority-queue-redis-streams-poc"],"tags_count":null,"template":false,"template_full_name":null,"purl":"pkg:github/fullzer4/adaptive-priority-queue-redis-streams-poc","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fullzer4%2Fadaptive-priority-queue-redis-streams-poc","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fullzer4%2Fadaptive-priority-queue-redis-streams-poc/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fullzer4%2Fadaptive-priority-queue-redis-streams-poc/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fullzer4%2Fadaptive-priority-queue-redis-streams-poc/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/fullzer4","download_url":"https://codeload.github.com/fullzer4/adaptive-priority-queue-redis-streams-poc/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fullzer4%2Fadaptive-priority-queue-redis-streams-poc/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31533824,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-07T16:28:08.000Z","status":"ssl_error","status_checked_at":"2026-04-07T16:28:06.951Z","response_time":105,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-04-08T00:02:05.765Z","updated_at":"2026-04-08T00:02:06.867Z","avatar_url":"https://github.com/fullzer4.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# adaptive-priority-queue-redis-streams-poc\n\nProof of concept of an adaptive priority queue built on Redis Streams, where all scheduling logic lives inside Redis as Lua Functions. Workers are intentionally dumb - they register, ask Redis what to process, execute, and report back. Redis handles everything else.\n\n---\n\n## The Problem\n\nGeneric worker pools processing heterogeneous task types hit a fundamental limitation with conventional queues: any static configuration will be wrong for at least one type. A small batch hurts throughput for burst-heavy types. A large batch hurts latency for uniform types. Static weights work until volume distribution changes - and it always does.\n\nThis system learns the behavior of each task type from observations and adjusts batch size, worker allocation, and consumption rate automatically. When a burst happens, the system detects the pressure and recovers. When the same burst happens again, it recovers faster because it already learned that type is volatile.\n\n---\n\n## When It Makes Sense\n\n- Generic workers processing task types with very different volumes and processing times\n- Most tasks can wait seconds or minutes - not everything needs sub-second latency\n- At least one task type is continuous, acting as a system health signal via cycle time\n- Task behavior changes over time and manual reconfiguration is not acceptable\n\nIf your workload is homogeneous and predictable, a well-tuned fixed batch size will perform just as well with far less complexity.\n\n---\n\n## What This POC Benchmarks\n\nThe same scenario runs against five implementations to isolate what each approach solves and where it breaks:\n\n| System | What it represents |\n|--------|--------------------|\n| `simple_list` | Redis LIST — no priority, no batching |\n| `sorted_set` | Pure priority via ZADD/ZPOPMIN — starvation under load |\n| `weighted_queue` | Static weights with tuned fixed batch — the \"this is enough\" argument |\n| `fixed_batch_stream` | Redis Streams without learning — isolates the adaptive B* effect |\n| `apq` | This system |\n\nThe key metric is **burst recovery time**: how long each system takes for the continuous task cycle time to return to baseline after a burst. Only this system should recover faster on the second burst than the first.\n\n---\n\n## Benchmark Timeline\n\nAll five systems run the same scenario sequentially and push metrics to Prometheus. A Grafana dashboard displays each system as a time-annotated timeline so behavior differences are visible at a glance — not just as final numbers.\n\nScenario events are marked as annotations on every panel:\n\n```\nt=0s    producers start — uniform, continuous, critical\nt=30s   first burst  — 5.000 tasks\nt=90s   second burst — 10.000 tasks\nt=150s  burst stops\nt=300s  scenario ends, next system starts\n```\n\nPanels per system, overlaid for direct comparison:\n\n| Panel | What to look for |\n|-------|-----------------|\n| Continuous task cycle time | Rises during burst, recovery speed after each burst |\n| Queue depth per priority | Which queues accumulate and how fast they drain |\n| Throughput (tasks/s) | Degradation during burst |\n| P95 latency per task type | Whether CRITICAL holds its SLO under load |\n| Starvation windows | How long LOW goes without processing |\n| B* over time *(APQ only)* | Adaptive batch size converging after each burst |\n| Pressure score *(APQ only)* | The single metric KEDA uses to scale pods |\n\nThe most important panel is cycle time across all five systems on a single graph with burst annotations. The gap between `weighted_queue` and `apq` recovery time on the second burst is the central argument of this POC.\n\n```bash\ndocker compose up -d          # Redis Cluster + Prometheus + Grafana\npython -m benchmark.setup     # initialize consumer groups\npython -m benchmark.runner    # runs all five systems sequentially (~25 min total)\n```\n\nGrafana at `http://localhost:3000` - dashboard auto-provisions on startup.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffullzer4%2Fadaptive-priority-queue-redis-streams-poc","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ffullzer4%2Fadaptive-priority-queue-redis-streams-poc","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffullzer4%2Fadaptive-priority-queue-redis-streams-poc/lists"}