TL;DR

Every few years, teams rediscover the same design dilemma: how should Maker-Checker be implemented at the database layer? This article breaks down three approaches—flag-based, draft tables, and versioned immutable rows—and explains why the last one saves you from those silent-room moments when critical requirements slip through the cracks.

The Silent Room

A few years ago, I was in a meeting that fell silent.

The team froze. Glances were exchanged. Pages flipped. And the uncomfortable truth emerged—a critical requirement had slipped through the cracks.

The Maker-Checker flow was missing.

Fast-forward to a few days ago. We were again discussing application architecture—this time with a fintech client. And once again, the same phrase echoed across the call:

“Maker-Checker is mandatory.”

It hit me—this is not a new discussion. It is a recurring one.

Every few years, teams rediscover the same design dilemma: How should Maker-Checker be implemented at the database layer?

So for everyone building systems that demand auditability, approvals, and compliance, here is a practical breakdown of the three design paths—and which one can save you from those silent-room moments.

Approach 1: Flag-Based

The simplest (and most tempting) option: Add a status column—DRAFT | PENDING | APPROVED | REJECTED.

Pros

  • One table, easy to implement
  • Minimal schema changes

Cons

  • One missed WHERE status='APPROVED' in a query, and drafts leak into reports
  • Old data gets overwritten—history lost
  • Unique constraints (like customer IDs) get messy fast

At first glance, it feels “done.” But under the surface, it is a ticking bomb.

Approach 2: Draft (Staging) Tables

A slightly safer road: separate tables for drafts and approved data.

Pros

  • Clean reporting—production reads only approved truth
  • Easy to lock down permissions

Cons

  • Now you manage two tables for every entity
  • Complex multi-table approvals (e.g., Policy + Riders + Beneficiaries) become painful

Better than flags, but brittle at scale.

Approach 3: Versioned Immutable Rows

The mature route—every change creates a new version row. Nothing is ever overwritten.

Pros

  • Bulletproof audit trail
  • Unique constraints apply only to current approved rows
  • Time-travel queries (“What did it look like last month?”) become trivial

Cons

  • Slightly heavier read logic—easily solved with a view

Example Implementation

1
2
3
4

CREATE VIEW customer AS
SELECT *
FROM customer_v
WHERE is_current AND status='APPROVED';

That one line ensures your app and reports never see drafts accidentally.

The Real-World Complexity

The challenge is not implementing Maker-Checker for a single table. The challenge is implementing it across related entities.

Consider an insurance policy:

  • Policy master record
  • Multiple riders
  • Multiple beneficiaries
  • Payment schedules
  • Endorsements

When a policy goes through Maker-Checker, all related records need to move together. A partial approval is not an approval—it is a data integrity nightmare.

The versioned approach handles this naturally. Each version of the policy can reference specific versions of riders and beneficiaries. The entire state is captured, not just individual rows.

Why This Matters for Fintech

In fintech and insurance, data is not just stored—it is trusted.

Regulators want to know what the record looked like at a specific point in time. Auditors want to trace every change. Compliance officers want to prove that no unauthorized modifications occurred.

Flag-based approaches fail this test. Draft tables make it cumbersome. Versioned immutable rows make it trivial.

The Lesson from That Silent Room

That frozen meeting years ago could have been a disaster. But it became a reminder: Maker-Checker is not a feature—it is a design philosophy.

Flags are shortcuts. Draft tables are scaffolds. But versioned, immutable rows with clean read views give you what every regulated system needs:

  • Trust
  • Auditability
  • Compliance

Choosing Your Path

If you were designing today, consider:

  • Flags work for simple systems with minimal audit requirements
  • Draft tables work when you need separation but can manage the complexity
  • Versioned rows work when you need a bulletproof audit trail and time-travel capability

For any system handling financial data, customer records, or regulatory compliance, the third option is almost always worth the initial investment.

The extra complexity upfront saves you from explaining to auditors why your data does not match what was approved.

What approach has worked for your Maker-Checker implementations? Have you found edge cases that challenged your design?

Editorial Note

This article was originally published on LinkedIn and has been revised for uk4.in.

Original publication date: 2025-10-04

Original link: https://www.linkedin.com/pulse/makerchecker-database-design-lesson-from-silent-room-uttam-jaiswal-yo4kc/