Abhishek Roka
Abhishek Roka

Why My Placement Portal Needs an Email Service Instead of Just an Email Function

When I initially implemented email functionality in my Placement Portal, I treated it like most developers would.

Generate the email.

Send it through the SMTP server.

Move on.

It worked perfectly for my password reset flow.

But as I continued building the product, I started noticing something.

Email was slowly becoming more than a function call.

It was becoming a communication layer between the platform and its users.

And once I started thinking about all the places where the Placement Portal could use email, the architectural problem became much larger.

That's when I started thinking about email as a dedicated service rather than just another utility function inside Django.

Where Email Is Used Today

Right now, email has a very specific responsibility in my Placement Portal.

Password reset.

A user requests a password reset, the backend generates the required credentials, and an email containing the reset link is sent to the user.

But that's only one possible use case.

As the Placement Portal grows, communication becomes increasingly important.

The platform needs a way to tell users when something important happens.

And email is one of the simplest ways to do that.

Email Has Multiple Responsibilities

Consider some of the communication workflows that could eventually exist inside the Placement Portal.

Security Notifications

Security-related events are natural candidates for email notifications.

For example:

These notifications aren't just informational.

They can also help users recognize activity they didn't initiate and build trust in the platform.

Job and Application Notifications

The Placement Portal is fundamentally about connecting students, companies, and placement teams.

That means there are many events that users may need to know about.

For example:

A user shouldn't necessarily have to keep opening the application just to check whether something changed.

The platform should be able to communicate important events proactively.

Bulk Announcements

This is where the problem becomes significantly different.

A placement coordinator may eventually need to communicate with hundreds or even thousands of students.

For example:

Sending one transactional email and sending thousands of announcement emails are fundamentally different workloads.

They have different requirements around:

That is another reason I don't want email to remain a simple function buried somewhere inside the application.

Invitation Emails

Another potential use case is account onboarding.

An administrator may create accounts for students or companies and then need to invite those users to the platform.

An invitation email could contain:

This becomes part of the user onboarding experience rather than simply being a technical email.

And once email starts becoming part of onboarding, notifications, security, and applications, it starts looking much more like a subsystem.

Different Emails Can Have Different Identities

Another architectural consideration I started thinking about is the sender identity.

Not every email necessarily needs to come from the same address.

For example, notification emails could potentially use an address such as:

notifications@example.com

While onboarding or invitation workflows could use something like:

onboarding@example.com

The exact addresses aren't important here.

The important part is the separation of responsibilities.

Different categories of emails can eventually require different:

If all of this logic is placed inside one generic email function, maintaining it becomes increasingly difficult.

Why Email Still Makes Sense

There are many communication channels available today.

Push notifications.

SMS.

In-app notifications.

Messaging platforms.

But email still has a major advantage.

Users already have it.

Most users already have an email account, and their phones can notify them when new messages arrive.

There is no additional application that needs to be installed just to receive an email.

There is also no requirement for the platform to build an entirely new communication channel from scratch.

For many product workflows, email provides a practical combination of:

That's especially useful when building and testing an early-stage product.

Email Is Also Cost Effective

Another reason email makes sense for my Placement Portal is its cost.

Imagine a college wants to experiment with the platform without immediately investing heavily in infrastructure.

For a smaller deployment, an email setup could start relatively simply with:

That can be enough for relatively small workloads.

As the platform grows, the underlying email provider can be changed to a dedicated email delivery service.

The important architectural idea is that the application shouldn't have to care too much about which provider actually delivers the message.

The application should care about the communication request.

The email infrastructure should handle the delivery.

That separation gives the system room to evolve.

Why Not Just Use SMS?

SMS is another obvious option for notifications.

But it introduces a different set of operational and financial considerations.

Depending on the provider and region, SMS can involve:

For a platform communicating with large numbers of students, those costs can become significant.

Email provides a much better starting point for my use case because it offers a strong balance between:

That doesn't mean SMS is useless.

There may be situations where SMS makes sense.

But it doesn't need to be the primary communication channel for everything.

From Email Function to Communication Service

This is the architectural shift I'm beginning to make.

Instead of thinking:

send_password_reset_email()

I'm starting to think in terms of:

Communication Service
        │
        ├── Password Reset
        ├── Security Notifications
        ├── Job Notifications
        ├── Application Notifications
        ├── Invitations
        ├── Bulk Announcements
        └── Future Channels

The goal isn't to build all of these features immediately.

The goal is to recognize that they are likely to become related responsibilities as the product evolves.

This gives me a better foundation for deciding where email-related logic should live.

Background Processing Becomes Important

Once email becomes a service, another architectural requirement becomes obvious.

Email shouldn't block the main application request whenever it doesn't need to.

This is why background task processing becomes important.

Instead of making the Django request wait for an SMTP server, the application can delegate email delivery to a background worker.

That allows the API to remain responsive while the communication layer handles delivery independently.

This is also where tools such as Celery become useful for my architecture.

The Django application can create a background task, and a worker can process the actual email delivery.

That gives the email subsystem its own processing layer instead of tying every email operation directly to the HTTP request.

What I Have Today vs. What I'm Planning

There is an important distinction here.

Today, my email functionality is primarily being used for password reset.

The broader email service architecture is something I'm designing as the Placement Portal grows.

Potential future responsibilities include:

I don't want to prematurely build every possible feature.

But I also don't want to design the current email functionality in a way that makes future expansion unnecessarily difficult.

That's the balance I'm trying to find.

Final Thoughts

One of the things I'm learning while building this Placement Portal is that seemingly small features can eventually become entire subsystems.

At first, email looked like this:

Generate Email → Send Email

Now I'm starting to see something more like:

Application
     ↓
Communication Service
     ↓
Background Tasks
     ↓
Email Provider
     ↓
User

The implementation may start with a password reset email.

But the architectural responsibility can eventually expand to notifications, invitations, announcements, security alerts, and other communication workflows.

That's why I no longer see email as just a utility function.

Email is a communication service waiting to emerge.

Sometimes scalable software isn't about adding more features.

It's about recognizing when a seemingly small feature is actually a subsystem waiting to emerge.

May the Force be with you.

— Abhishek Roka