While building a real project, I ran into a design decision that looked small on the surface, but turned out to teach me something big about how backend systems are structured.

I am not a professional developer yet. I am learning, building things, making mistakes, and figuring stuff out as I go. Recently, I was implementing audit logging for my Spring Boot project, basically keeping a record of "who changed what and when."

That's when I discovered there are two very different ways to write the same feature. And the difference isn't what I expected.

what is audit logging?

Before we get into the design debate, a quick note on what audit logging is. It's a trail of records that says things like: "User john updated Transaction 101 on Tuesday, changing the amount from ₹500 to ₹750." These logs are critical in any business application for debugging, compliance, and accountability.

So the goal is simple: every time something important changes in the system, save a log of it. The tricky question is how.

The two approaches I found

Approach 1 - The service builds the object

Here, the service method accepts individual values and handles everything

public void log(String entityType, Long entityId, String action,
                String performedBy, String username,
                String oldVal, String newVal, String source) {

    repo.save(AuditLog.builder()
        .entityType(entityType)
        .entityId(entityId)
        .action(action)
        .performedBy(performedBy)
        .performedByUsername(username)
        .oldValue(oldVal)
        .newValue(newVal)
        .source(source)
        .build());
}

When other methods calls this, it looks like.

auditService.log(
    "Transaction", 101L, "UPDATE",
    "EMP001", "john",
    oldJson, newJson, "WEB"
);

The caller doesn't need to think about AuditLog at all.

Approach 2 — the caller builds the object

Here, whoever is calling the method builds the object themselves:

AuditLog audit = AuditLog.builder()
    .entityType("Transaction")
    .entityId(101L)
    .action("UPDATE")
    .build();

auditService.log(audit);

The service just saves it to the database.

public void log(AuditLog auditLog) {
    auditLogRepository.save(auditLog);
}

Why Approach 1 is preferred in most business apps

If in future we need to add extra fields like sessionID, deviceInfo in every audit record.

With Approach 1, you change one place — the service method. Every single caller automatically benefits. No one has to update their code.

With Approach 2? Every piece of code that creates an AuditLog.builder() needs to be found and updated. If three different developers wrote three different callers, you might end up with:

Developer A: .action("UPDATE")
Developer B: .action("updated") // inconsistent

Your audit data becomes a mess. Approach 1 prevents this by centralizing the construction logic.

So when is Approach 2 actually the right choice?

Approach 2 isn't wrong it's just for different situations. It shines when the callers genuinely need control over the object:

• Kafka consumers or batch jobs that produce their own structured audit data
• External system integrations where the full object already arrives pre-built

What I actually learned from this:

• The same feature can be designed in fundamentally different ways, and the difference matters.
• Centralized construction = easier maintenance, Caller construction = more flexibility.

I'm still early in my learning journey, and I find that the most useful things I pick up come from real decisions in real projects not just tutorials. If you're in the same boat, I hope this helped. It definitely made me think differently about how I structure service methods.