The Problem: Vendor Lock-In By Design
A developer at an unnamed Brazilian company faced a familiar enterprise problem: their engineering manager asked for a cost analysis of transactional email services. The company used SendGrid across four web applications and needed to scale to 250,000 emails monthly for their main product.
The analysis found cheaper alternatives with better features. But the real cost emerged during implementation planning: developer time. Switching providers across four applications would take months of sprint time, pulling engineers off core features. The email logic was tightly coupled to repositories, regardless of whether they used functional programming or "almost clean architecture."
The company stayed with SendGrid. Not because it was the best option, but because the technical debt made switching prohibitively expensive.
The Solution: Adapter Pattern For Email
The developer, who goes by carol8fml on GitHub, built Nexus Notification Hub as a proof of concept. The architecture uses NestJS and Nx with classic design patterns to decouple notification logic from provider implementations.
The core is simple: a NotificationProvider interface that any email service must implement. Whether SendGrid, AWS SES, or Mailtrap, each provider gets an adapter that translates between the common interface and the service's specific API.
A factory pattern centralizes the "which provider" decision. The controller and business logic never know which service is actually sending emails. They work against abstractions.
What This Means In Practice
Switching providers becomes: create a new adapter file, change one configuration line, done. The repository is public on GitHub.
This is a common enterprise architecture problem. Legacy systems accumulate vendor dependencies that become expensive to unwind. The pattern here applies beyond email: payment gateways, SMS services, cloud storage.
The interesting part isn't the technical pattern (adapter pattern is decades old). It's that a mid-level developer built this because their company got stuck. That's how technical debt actually gets paid down: engineers solving their own frustrations.
Worth noting: the original problem was scale-driven (250k emails monthly). For smaller operations, tight coupling might be fine. The architecture overhead only makes sense when switching costs exceed building costs.