{"id":21182681,"url":"https://github.com/guilhermebkel/e-commerce-microservices-case-study","last_synced_at":"2025-10-04T05:04:50.477Z","repository":{"id":165592990,"uuid":"275925101","full_name":"guilhermebkel/e-commerce-microservices-case-study","owner":"guilhermebkel","description":":crown: A deep study about microservices architecture by the example of an e-commerce application","archived":false,"fork":false,"pushed_at":"2020-07-05T18:20:38.000Z","size":845,"stargazers_count":14,"open_issues_count":0,"forks_count":2,"subscribers_count":5,"default_branch":"master","last_synced_at":"2024-05-27T20:34:00.915Z","etag":null,"topics":["api-gateway","buffalo","celery","django","docker","elasticsearch","golang","kubernetes","lambda","loopback","nestjs","nodejs","python","rabbitmq","redis","serverless","sqlite"],"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/guilhermebkel.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,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-06-29T21:00:27.000Z","updated_at":"2024-06-19T13:20:28.067Z","dependencies_parsed_at":"2024-06-19T13:20:13.869Z","dependency_job_id":"b9f2215a-db7d-4522-bd45-d9a896dff8c3","html_url":"https://github.com/guilhermebkel/e-commerce-microservices-case-study","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/guilhermebkel%2Fe-commerce-microservices-case-study","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/guilhermebkel%2Fe-commerce-microservices-case-study/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/guilhermebkel%2Fe-commerce-microservices-case-study/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/guilhermebkel%2Fe-commerce-microservices-case-study/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/guilhermebkel","download_url":"https://codeload.github.com/guilhermebkel/e-commerce-microservices-case-study/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":225606621,"owners_count":17495551,"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":["api-gateway","buffalo","celery","django","docker","elasticsearch","golang","kubernetes","lambda","loopback","nestjs","nodejs","python","rabbitmq","redis","serverless","sqlite"],"created_at":"2024-11-20T17:57:39.432Z","updated_at":"2025-10-04T05:04:50.387Z","avatar_url":"https://github.com/guilhermebkel.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003c!-- \u003cp align=\"center\"\u003e\n\t\u003cimg src=\"./assets/icon_example.png\" height=\"150\" width=\"150\" alt=\"icon example\" /\u003e\n\u003c/p\u003e\t --\u003e\n\n\u003ch3 align=\"center\"\u003e\n A deep study about microservices architecture by the example of an e-commerce application 💍\n\u003c/h3\u003e\n\n## 📌 Overview\n\nThat's a simple SaaS E-Commerce platform example, to make a study about microservices.\n\n## 🎆 Case Study\n\n- The client can subscribe to have its own store in minutes\n- All the platform will be multi tenant, so, it will not be duplicated to every customer. Every customer will see only its own data\n- The customer will have a temporary domain and will be able to specify a main domain when the store goes up\n- The customer will have a admin panel to manage its products\n- The customer will be able to see the requested products\n- By default the store will use **pagar.me** as the payment gateway, but the system will be able to accept another gateways\n- The store will have a search area\n- The store will have a custom logo\n- The store will not have a customer area, neither an authentication area, only a checkout area\n\n## 🔧 Technologies\n\n- Golang\n- Docker\n- Django\n- Celery\n- Redis\n- SQLite\n- Nest.js\n- Node.js\n- Loopback\n- ElasticSearch\n- Serverless\n- RabbitMQ\n- Buffalo\n- API Gateway\n- Lambda\n- Python\n- Kubernetes\n\n## 🧿 Microservices\n- [Signatures **(Golang / Buffalo)**](https://github.com/codeedu/maratonafc3p-microsservico-assinaturas)\n  - Landing Page\n  - Plans\n  - Signature Process\n  - In case the signature is made with success, its info is sent to a store manage microservice\n\n- [Payments **(Serverless / API Gateway / Golang)**](https://github.com/codeedu/maratonafc3-microsservico-pagamentos)\n  - Process all payments and persists the data on a database\n  - Single payment transactions\n  - Signature creation transactions\n\n- [Administrator **(Python / Django / Celery / Redis)**](https://github.com/codeedu/maratonafc3-repo-main/tree/master/commerce-admin)\n  - Make the multi tenant environment\n  - Admin area\n  - Send the created/updated products to a queue\n\n- [Store **(Nest.js / Node.js / Loopback / ElasticSearch)**](https://github.com/codeedu/maratonafc3-repo-main/tree/master/commerce-shop)\n  - Sync the received products by administrator microservice on the ElasticSearch\n  - Use the payment microservice in a sync way\n  - The created purchases are sent to a queue\n\n## 🗿 Monolithics vs Microservices\n### Monolithics\nThat's a single application, with different contexts running in the same application.\n\nThe **good points** are:\n- Since everything is coupled, it is easier to deal with communication between contexts.\n\nThe **pain points** are:\n- If a context goes down, everything goes down (Per ex: if you have lot of access on the Checkout module and I goes down, every other module will probably go down as well);\n- The more your team grows, the more complex it becomes to manage how they maintain the system, since they're able to change a context of another team;\n- If you have to scale some context, you've to duplicate all system and scale everything together.\n\n### Microservices\nThey are divided in product contexts (so it is recommended to implement them if you have business issues, not technical issues), not in modules. Some examples of contexts that a product can have: Marketing, Law, Selling.\n\nIt is recommended to have a single database per microservice (in order to keep it decoupled as you can).\n\nThe microservice must have a fallback rule, it must be written to fail and to deal with fail (without making another microservice fail if there's communication between them)\n\nThe **good points** are:\n- If some context goes down, the others stay up;\n- A team can manage its own context without accessing another;\n- You can scale a unique context;\n- You have specialized teams by contexts;\n- You can use different technologies by contexts.\n\nThe **pain points** are:\n- Since everything is not coupled, you've to deal with distributed communication.\n\n## 📨 Distributed Message Queue System\n\nThat's generally a queue which you can use to put some messages inside it and read some messages from it as well. Usually you have the following stuff working around it:\n\n- **Publisher:** is able to put/create messages on the queue.\n- **Consumer:** is able to get/read messages from the queue.\n- **Queue:** is able to store messages inside it for some time till some service reads or deletes the message from it.\n- **Dead Letter Queue:** is able to retain the message that has not been processed after some attempts.\n- **Direct Exchange:** is able to send a message direct to a single queue consumer that is listening to it.\n- **Fanout Exchange:** is able to send a message for all the consumers that are listening to a queue.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fguilhermebkel%2Fe-commerce-microservices-case-study","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fguilhermebkel%2Fe-commerce-microservices-case-study","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fguilhermebkel%2Fe-commerce-microservices-case-study/lists"}