Building a Configurable Resume Management System with Future Redis Caching

Today, I removed another hardcoded value from my Placement Portal.

Previously, I had hardcoded the maximum number of resumes a student could upload. While that works perfectly fine for an MVP, it becomes difficult to maintain as soon as different institutions require different policies.

Instead of hardcoding business rules, I decided to make them configurable.

What I Implemented

The implementation consists of three simple components:

• A configuration model to store application settings.
• Django Admin integration for managing configuration values.
• A helper function to fetch configuration values throughout the project.

Currently, the configuration model stores the maximum number of resumes a student is allowed to upload.

Why Use a Helper Function?

One obvious question is:

Why not simply call ResumeConfig.objects.first() whenever the value is required?

The answer is scalability.

Every ORM query eventually becomes a database query. If I repeatedly fetch the same configuration value on every request, the database will spend its time serving data that rarely changes.

By introducing a helper function, I have created an abstraction layer between my business logic and the underlying storage mechanism.

Today, the helper function fetches values from the database.

Tomorrow, it may fetch them from Redis.

The rest of the application won't need to change.

Preparing for Redis Caching

One of the reasons I intentionally introduced this abstraction is future Redis integration.

Configuration values are ideal candidates for caching because they:

• Change infrequently.
• Are read frequently.
• Are required by multiple components of the system.

The future workflow will look something like this:

1. Administrator updates a configuration value.
2. The database is updated.
3. Redis cache is refreshed.
4. Every subsequent request reads the configuration from Redis instead of the database.

This approach provides two major benefits:

• Faster response times.
• Reduced database load.

Why Avoid Unnecessary Database Queries?

The database is the single source of truth for the entire application.

Its primary responsibility should be handling business-critical operations such as:

• User authentication.
• Password updates.
• Job application creation.
• Resume uploads.
• Job posting.
• Profile management.

Frequently reading configuration values that rarely change is not an efficient use of database resources.

Caching allows the database to focus on operations that actually require transactional consistency.

Designing for Future Products

Another reason I introduced the helper function is future product expansion.

Today, I am building a Placement Portal.

Tomorrow, I may decide to introduce a Training Portal for industry-led training programs.

Both products may share:

• Authentication
• User management
• Resume management
• Configuration management
• Email modules

However, certain configuration values and business rules may differ.

Instead of rewriting everything from scratch, I can simply provide different implementations behind the helper functions or configuration modules while reusing the majority of the existing architecture.

Small abstractions today can save significant development time in future products.

Final Thoughts

This feature isn't particularly flashy. Students won't even notice it exists.

However, good software architecture is often invisible.

Removing hardcoded business rules, introducing configuration management, and preparing for caching are the kinds of engineering decisions that make a project easier to scale and maintain over time.

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