[Docs] Document each service's internal architecture in its own README

[sharmavaibhav31]

Each service directory has a top-level README.md placeholder. This issue is about filling them in one per service, covering: what the service does, its key files, how to run it in isolation, and how it connects to the rest of the pipeline. Good for someone who wants to deeply understand one service before contributing code.

[ArpitKumar8649]

Hi @sharmavaibhav31 ,
This looks like a great way to dive deep into the architecture of the pipeline! I would love to take this up and document the internal architecture, key files, and isolation steps for these services.
I am participating in GSSoC '26. Could you please assign this issue to me? I can start mapping out the first service's README right away.
Thanks!

[sharmavaibhav31]

Assigned.

Note:
Please keep one README per service directory and maintain a consistent structure across all of them.

Each service README should briefly cover:

• purpose of the service
• request/data flow
• important files/modules
• how to run it independently and locally
• environment variables
• how it interacts with other services
• common debugging/setup notes
• example requests/workflows where applicable

Please keep this issue documentation-focused and avoid changing architecture or implementation logic.
Try to maintain a consistent structure/style across all service READMEs so contributors can navigate the repo easily.
AI tools are fine for assistance, but make sure all documentation is accurate, repository-specific, and verified against the actual codebase. Avoid generic or AI-generated placeholder explanations.

You can also open a draft PR after documenting the first service if you'd like early feedback before continuing with the remaining services.

[ArpitKumar8649]

Hi @sharmavaibhav31,
I have opened Draft PR #27 with the README for the email-generator-service as our first test run.
Could you please take a quick look when you have a moment to ensure the formatting, structure, and depth align exactly with what you are looking for? Once you give the green light, I will go ahead and knock out the documentation for the remaining services.
Thanks!

[sharmavaibhav31]

Hi @ArpitKumar8649,

Thanks for the detailed work on the service documentation - the internal flow explanations and module breakdowns are definitely helpful.

While reviewing, I noticed that a significant portion of the operational/API documentation you added already exists in the current service README files. This went unnoticed on my side because the repository structure and documentation evolved a bit after the original issue was created.

To keep the documentation consistent and avoid duplication across services, I’d like to slightly narrow the scope of this issue.

Instead of expanding the existing API/setup sections further, could you focus more on the contributor-oriented/internal architecture parts, such as

• request/data flow
• service interactions
• important modules/files
• debugging notes
• internal execution pipeline

Those sections add the most value right now and are still missing across several services.

The additional operational/API documentation you added is still useful, and I may create a separate follow-up docs issue specifically for enhancing service-level usage documentation.

[bhaveshksahu]

Hi @sharmavaibhav31! I'm a GSSoC '26 accepted contributor interested in working on this issue. I have a Python background and this looks like a great starting point for me. Could you please assign this to me? I'll read through all the services carefully and write clear, structured README documentation for each. Happy to deliver quality work!

[ArpitKumar8649]

Hi @sharmavaibhav31! I'm a GSSoC '26 accepted contributor interested in working on this issue. I have a Python background and this looks like a great starting point for me. Could you please assign this to me? I'll read through all the services carefully and write clear, structured README documentation for each. Happy to deliver quality work!

Brother, this issue had already assigned to me . You can try other one. I have already completed my works on it and it's in draft for review.

[HarshParmar029]

Hi @sharmavaibhav31,

I would like to work on this issue.

I plan to implement a clean one-command reset script that:

• clears Redis Streams safely
• resets PostgreSQL state (as applicable)
• ensures all services return to a clean dev state
• includes confirmation prompt to prevent accidental data loss

I will keep the solution simple, well-documented, and aligned with existing project scripts.

Please assign this issue to me. Thanks!

[sharmavaibhav31]

Hey @HarshParmar029 I think you have commented the wrong issue!