"The Universal Adaptor"
You requested that this service "contain only code of provider" and be usable from "different places for different purposes".
Here is the strict boundary of what code lives inside apps/communication.
✅ IN SCOPE (The "Husk")
This service is purely a Delivery Infrastructure layer.
-
Provider Registry:
- Code connecting to Twilio, standard SMTP, AWS SES, Resend.
- Code connecting to "Custom Providers" (Webhooks).
- NO business rules here. Just
provider.send().
-
Credential Vault:
- Logic to securely fetch and decrypt Tenant API Keys.
- "Which API Key do I use for Tenant X?"
-
Traffic Control (The Gateway):
- Queues: Buffering requests so we don't crash the provider.
- Rate Limiting: "Don't send more than 10 SMS/sec to Twilio".
-
Feedback Loop:
- Receiving Webhooks from Twilio ("Delivered", "Failed").
- Normalizing them into a standard format (
MessageEvent).
❌ OUT OF SCOPE (The "Brain")
This service acts as a robot. It does not think.
-
Content Generation:
- It does NOT decide "What should the Welcome Email say?".
- The Caller (Manager/Newsletter) must send the final HTML or Text.
- Exception: It can pass
templateId+variablesif the Provider (like SendGrid) handles templating.
-
Business Logic:
- It does NOT know what an "User" is.
- It does NOT know what an "Invoice" is.
- It does NOT know "If user is premium, send SMS".
-
Scheduling:
- It does NOT decide "Send this next Tuesday". (Newsletter Service does that).
- It only knows "Send
NOW".
Interface
- Input:
TenantID,ProviderType,Credentials(Optional override),Content(HTML/Text). - Output:
Success/Failure.
Why this fits your plan
- Manager Service uses it for OTPs.
- Newsletter Service uses it for Campaigns.
- Billing Service uses it for Receipts.
- Any Future Service can plug in.
It is a Stateless Execution Engine.