Why I Added Snapshot Fields to Job Applications in My Placement Portal

Today, I completed two important features on the student side of my Placement Portal:

• Application Listing
• Application Details

To keep the user experience consistent, I designed these pages using the same layout as the Job Listing and Job Details pages, with additional information that is specific to an application.

While the UI changes were straightforward, the more interesting work happened in the backend.

The Problem

Initially, an application only stored references to a student and a job.

That seemed sufficient until I thought about a simple scenario.

What happens if:

• A recruiter edits the job description?
• The salary package changes?
• The student updates their phone number or email address?

If the application only references the latest records, it no longer reflects what actually existed when the student applied.

An application should be a historical record—not just a relationship between two tables.

The Solution: Snapshot Fields

To preserve that history, I introduced snapshot fields into the Application model.

For every application, I now store:

Job Snapshot

• Job Title
• Job Description
• Job Location
• Salary (CTC)

Student Snapshot

• Student Email
• Phone Number
• WhatsApp Number

These values are copied into the application when it is created.

Even if the original job posting or student profile changes later, the application continues to represent the exact information that existed at the time of submission.

Why Snapshot Data Matters

Imagine a recruiter updates a job's salary after applications have already been received.

Without snapshot fields, every historical application would suddenly appear to reference the new salary.

The same problem exists if a student updates their contact details.

By storing a snapshot, both students and recruiters can always answer an important question:

"What exactly was submitted when this application was created?"

This makes the application a reliable historical record.

Updating the API Layer

The database changes also required updates to the API.

Instead of relying on a single serializer, I created two dedicated serializers.

Application List Serializer

Returns only the information needed for quick browsing:

• Job Title
• Company
• Application Status
• Applied Date

Application Detail Serializer

Returns the complete application, including the snapshot fields and detailed job information.

This keeps list responses lightweight while providing richer information only when requested.

Updating the Business Logic

The application creation workflow also needed to change.

When a student applies for a job, the backend now:

1. Retrieves the selected job.
2. Retrieves the authenticated student's profile.
3. Copies the required job and student information into the snapshot fields.
4. Saves the application.

From that point onward, the application becomes an independent historical record.

For the list and detail APIs, I also ensure that students can only access applications they have personally submitted.

Final Thoughts

Today's work reminded me that designing a database isn't just about connecting tables.

It's about deciding which information should remain dynamic and which should be preserved forever.

In this case, preserving a snapshot of the job and student details makes every application more reliable, easier to audit, and resilient to future changes.

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