Designing User Management for a Placement Portal: My First Architectural Decision
When I started building my Placement Portal, I realized that writing code wasn't the first challenge.
The real challenge was answering a much simpler question:
Who should be allowed to do what?
Every software system starts with users. If user roles aren't designed properly, the rest of the application eventually becomes difficult to maintain.
So before writing a single authentication API, I decided to design the user architecture.
Identifying the Core Users
After studying how placement cells actually operate, I identified four primary users of the system.
- Admin
- University
- Company
- Student
Each of them interacts with the system differently.
Admin
The Admin has complete control over the portal.
Responsibilities include:
- Managing all users
- Creating job postings on behalf of companies
- Performing CRUD operations across all entities
- Monitoring the overall system
University
A University administrator has almost the same permissions as the Admin, but only for their own institution.
They can:
- Manage students
- Publish company opportunities
- View applications
- Maintain university-specific placement records
Company
Companies only need access to information relevant to their recruitment process.
They can:
- Create and manage their own job postings
- View applicants for their jobs
- Track application status
They cannot access unrelated student records or jobs posted by other companies.
Student
Students interact with the portal very differently.
They can:
- Create and update their profile
- Upload resumes
- View jobs relevant to their department or branch
- Apply for jobs
- Track application status
Their profile contains important information such as:
- Personal details
- Contact information
- Academic records
- Skills
- Achievements
- Certifications
- Volunteering experience
The Real Challenge
Designing user interfaces is easy.
Designing permissions is much harder.
Instead of creating completely separate login systems for every user type, I researched how large platforms solve this problem.
One interesting example is WhatsApp.
A person can own both:
- WhatsApp Business
They represent different identities while still belonging to the same underlying user.
That inspired my architecture.
Introducing the Base User
Instead of maintaining separate authentication logic for Students, Companies, Universities, and Admins, I decided to introduce a single Base User model.
Every user shares a few common attributes:
- Email (unique)
- Phone Number
- Password
- Active Status
- Role
- Staff Status
These fields belong to authentication rather than business logic.
Role-specific information is stored separately.
For example:
- Student details belong to the Student profile.
- Company details belong to the Company profile.
- University information belongs to the University profile.
This keeps authentication simple while allowing each role to evolve independently.
Why Separate Profiles?
Suppose a student wants to change their email address.
Only the Base User needs to be updated.
Suppose they earn a new certification.
Only the Student profile changes.
Authentication data remains isolated from business data.
This separation makes the application:
- Easier to maintain
- Easier to scale
- Easier to secure
- Easier to extend with future roles
Current Limitation
At the moment, one Base User can have only one role.
A student cannot simultaneously become a company user.
This mirrors how the placement process typically works in real-world universities and keeps permission management straightforward.
If future requirements change, supporting multiple roles can be added without redesigning the authentication system.
What's Next?
Now that the user architecture is finalized, the next milestone is implementing:
- Base User model
- Authentication
- Authorization
- Role-based access control
- Login APIs
Everything else in the Placement Portal will build on this foundation.
Final Thoughts
Many developers jump directly into coding.
I prefer spending time designing the architecture first.
Good architecture reduces future complexity, improves maintainability, and makes scaling much easier.
This is just the beginning of building the Placement Portal in public.
I'll continue documenting every major design decision throughout the project.