docs(readme): lead with why the system exists - #27
Merged
Conversation
The intro described a hypothetical user watching 'a few thousand sources'. The real driver is stronger and more specific: a Hagalink project monitoring more than 10,000 RSS sources with keyword alerting, which is why the capacity benchmark tops out at exactly 10,000 and why the runtimes are split the way they are. Adds a Deployment section stating what Kubernetes buys over Compose here -- queue-depth autoscaling, which Compose cannot express -- and links the CI that applies the manifests to a real cluster.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The README opened with a hypothetical user — "the person who has to watch a few thousand sources" — when the actual driver is more specific and more convincing.
What changes
A
Why it existssection up top. Built for a Hagalink project monitoring more than 10,000 RSS sources with keyword alerting. Hosted readers are priced per seat, built for a human reading a timeline, and do not offer keyword rules with multi-channel alerting or an API to plug matches into.That reframes something already in the repo: the capacity benchmark tops out at exactly 10,000 feeds because that was the acceptance criterion, not a round number chosen to look good. Same for the architecture — three runtimes because the API, scheduler and fetching have unrelated load profiles.
A
Deploymentsection. States the real trade-off rather than assuming Kubernetes is better: Compose is simpler and cheaper at low feed counts and is what this ran on first. Kubernetes earns its place for one property Compose cannot express — the worker scales on queue depth, not CPU, because it blocks on network I/O against slow feeds while the backlog grows.Also links the CI that applies the manifests to a real kind cluster, and points at #24 for the honest crossover analysis: the range where Kubernetes is the wrong choice.
Kubernetes CI badge alongside the others.
No claims about client commercials or identity — the framing is Hagalink's own project and the numbers are the ones this repository already measures.