{"id":17767902,"url":"https://github.com/marceloboeira/crowd","last_synced_at":"2025-07-20T12:36:31.352Z","repository":{"id":71790258,"uuid":"161028746","full_name":"marceloboeira/crowd","owner":"marceloboeira","description":"👥 [WIP] An experimental High Available Reverse Proxy for Massive Asynchronous Message Consumption","archived":false,"fork":false,"pushed_at":"2019-07-10T15:27:02.000Z","size":572,"stargazers_count":6,"open_issues_count":3,"forks_count":1,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-04-01T15:41:58.641Z","etag":null,"topics":["asynchronous","back-pressure","entrypoint","fan-out","high-availability","ingestion","kafka","message-queue","queue","rabbitmq","redis","reverse-proxy","sqs","stream"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/marceloboeira.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2018-12-09T10:39:46.000Z","updated_at":"2024-03-26T18:43:19.000Z","dependencies_parsed_at":null,"dependency_job_id":"23925bcd-39fd-4fc0-9567-7f09851c33c9","html_url":"https://github.com/marceloboeira/crowd","commit_stats":null,"previous_names":["14bits/crowd","14-bits/crowd"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/marceloboeira/crowd","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/marceloboeira%2Fcrowd","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/marceloboeira%2Fcrowd/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/marceloboeira%2Fcrowd/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/marceloboeira%2Fcrowd/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/marceloboeira","download_url":"https://codeload.github.com/marceloboeira/crowd/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/marceloboeira%2Fcrowd/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":266127267,"owners_count":23880425,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","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":["asynchronous","back-pressure","entrypoint","fan-out","high-availability","ingestion","kafka","message-queue","queue","rabbitmq","redis","reverse-proxy","sqs","stream"],"created_at":"2024-10-26T20:51:59.841Z","updated_at":"2025-07-20T12:36:31.291Z","avatar_url":"https://github.com/marceloboeira.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003cp align=\"center\"\u003e\n  \u003cimg src=\"https://github.com/14bits/crowd/blob/master/docs/logo.png?raw=true\" width=\"200\"\u003e\n  \u003ch3 align=\"center\" style=\"margin-top: -100px\"\u003ecrowd\u003c/h3\u003e\n  \u003cp align=\"center\"\u003eHigh Available Reverse Proxy for Asynchronous Message Consumption\u003cp\u003e\n  \u003cp align=\"center\"\u003e\n    \u003ca href=\"https://travis-ci.org/14bits/crowd\"\u003e\u003cimg src=\"https://img.shields.io/travis/14bits/crowd.svg?maxAge=120\"\u003e\u003c/a\u003e\n    \u003ca href=\"http://github.com/14bits/crowd/releases\"\u003e\u003cimg src=\"https://img.shields.io/github/release/14bits/crowd.svg?maxAge=120\"\u003e\u003c/a\u003e\n  \u003c/p\u003e\n\u003c/p\u003e\n\n## Status\n\n⚠️  At the moment the project is just a spike, don't take it too seriously.\n\n## Motivation\n\nThe project started because of a common usecase for an endpoint (HTTP) to ingest data, where the user on the client side expects to receive a delivery confirmation that the message has been received, yet the response itself doens't matter.\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"https://github.com/14bits/crowd/blob/master/docs/problem.png?raw=true\" width=\"500\"\u003e\n\u003c/p\u003e\n\nOn a company that I used to work for, that was the case for the entry point of leads, which is the source of 💰 that must be always available.\n\nAs the image above shows, both the **database writes** and **mailing** were triggered on time of the request. We'll have seen that, is a pretty common pattern. The problem is that scaling it creates all sorts of issues, mostly unnecessary ones. People try to scale the database to handle the back-pressure, which even if you have to do it, you don't want to depend entirely on a database write to handle enormous data ingestion.\n\nAlso, you probably handle different loads during the day, or time of the year, which would make you pay for a database on the worst-case-scenario but only make use of it during the spikes.\n\ne.g.:\n\nRequest:\n```\nPOST /leads HTTP/1.1\nContent-Type: application/json\nAccept: application/json\nContent-Length: 327\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.1 Safari/605.1.15\n\n{\"message\":\"this is a lead message\", \"shop\": \"a23m07b23\"}\n```\n\nResponse:\n```\nHTTP/1.1 200\nContent-Type: application/json;charset=UTF-8\nVary: Accept-Encoding\nConnection: keep-alive\nDate: Sun, 09 Dec 2018 11:07:54 GMT\nContent-Encoding: gzip\nTransfer-Encoding: Identity\n\n{\"status\": \"OK\"}\n```\n\n### crowd: An alternative\n\nThe whole point of crowd is to have a **high available** endpoint to avoid package loss, disregarding the processing. If you need to return something to the user on the time of the request, it's probably not for you.\n\nWhich is a quite common pattern for data-ingestion in general: statistics, events, tracking, order-placement, queue items, ...\n\nThat way you can easily control an acceptable throughput to the rest of your system.\n\nYou can use crowd to handle back-pressure on existing endpoints and scale your current REST APIs to consume the messages later:\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"https://github.com/14bits/crowd/blob/master/docs/usecase-1.png?raw=true\" width=\"500\"\u003e\n\u003c/p\u003e\n\nOr even as an entrypoint to your stream/queues with multiple consumers:\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"https://github.com/14bits/crowd/blob/master/docs/usecase-2.png?raw=true\" width=\"500\"\u003e\n\u003c/p\u003e\n\n### Disclaimer\n\nIt is important to notice that, for most projects, you could probably rewrite your endpoints to push directly to queues and call it a day. However, the scenario where this idea was conceived would involve having to come up with a standard way of doing this across multiple languages, frameworks, teams,... which would be more expensive than implementing only once and solving it as an infrastructural problem.\n\n# Contributing\n\n## Commands\n\n```\nmake help                           Lists the available commands\nmake install                        Installs app dependencies\nmake run                            Runs the app\nmake test                           Runs tests\nmake compose                        Runs docker compose dependencies\nmake decompose                      Stops docker compose dependencies\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmarceloboeira%2Fcrowd","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmarceloboeira%2Fcrowd","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmarceloboeira%2Fcrowd/lists"}