Designing Resume Upload During Job Applications in My Placement Portal

Today, I implemented the resume upload workflow during job applications in my Placement Portal.

At first glance, it looks like a simple feature:

Upload a resume and apply for a job.

But once I started designing the workflow, I realized there were several product and architectural decisions involved.

The Application Flow

Initially, the application flow was extremely simple.

• Student clicks on the Apply button.
• The application record gets created.

Now, the workflow has become more informative and realistic.

• Student clicks on the Apply button.
• Student chooses an existing resume or uploads a new one.
• The uploaded resume is validated.
• If valid, the resume is stored in the system.
• Student confirms the application.
• The job application gets created.

This extra step ensures that every application has an associated resume before it reaches the recruiter.

Resume Validation

While uploading a resume, I currently validate two basic things:

• The file size must remain within the configured limit.
• The file must be a PDF document.

If validation fails, the portal immediately informs the student through toast notifications.

Otherwise, the system:

• Uploads the resume.
• Extracts the file name.
• Calculates the file size.
• Stores the file in server storage.
• Creates the corresponding database record.

The goal is to make the process informative rather than silently failing.

Why Multiple Resumes?

One question I asked myself during development was:

Why not allow only one resume per student?

The answer is simple.

Students often apply for different roles.

For example, a student may simultaneously apply for:

• Backend Developer
• Frontend Developer
• Data Analyst
• Software Engineer Intern

Each role may require a slightly different resume.

Restricting students to a single resume would unnecessarily limit their opportunities.

That is why I decided to allow multiple resumes per student.

Currently, the limit is set to 10 resumes.

Making Limits Configurable

Initially, I considered limiting students to only two or three resumes.

However, another question came to mind.

What if a university wants to change the limit?

If I hardcode the limit inside the project, every requirement change would require:

• Updating the code.
• Creating a new release.
• Deploying the application again.

That approach doesn't scale well for a multi-institution portal.

Instead, I am planning to move these limits into a configurable setting managed by administrators or universities.

For example, administrators should be able to configure:

• Maximum resumes per student.
• Resume size limits.
• Future application-related restrictions.

This makes the system significantly more flexible without requiring engineering changes for every policy update.

Using Redis for Configuration Caching

Once configuration becomes dynamic, another problem appears.

Every resume upload would require a database query to determine the allowed limits.

That means:

• Fetch configuration.
• Validate limits.
• Process the upload.

Performing database lookups on every request isn't ideal.

My current plan is to cache these configuration values using Redis.

The workflow would look something like this:

• Administrator updates the configuration.
• The configuration table gets updated.
• Redis cache gets refreshed.
• Resume uploads read configuration values directly from Redis.

This allows the application to remain flexible while avoiding unnecessary database hits.

Final Thoughts

What started as a simple resume upload feature eventually became a discussion about product design and software architecture.

Sometimes, the most interesting engineering decisions are not about writing code—they're about deciding which values should remain hardcoded and which should become configurable.

The more I work on this Placement Portal, the more I realize that building scalable software is often about designing good abstractions rather than adding more features.

I'm documenting every engineering and product decision while building this Placement Portal in public.