Data Integrity Challenges - Learning Module

Loading content...

0/241

Application Enforcement

Consistency at the Application Layer

While database triggers offer automatic, guaranteed enforcement of denormalization consistency, they are not always the optimal choice. Complex business logic, cross-service data synchronization, polyglot persistence, and advanced error handling often require consistency enforcement at the application layer.

Application-level enforcement places the responsibility for maintaining denormalized data consistency within your application code—typically in service classes, domain models, or specialized synchronization components. This approach offers flexibility that database triggers cannot match, but it demands disciplined architectural design and rigorous testing.

This page provides a comprehensive exploration of application-level consistency enforcement. We'll examine when to choose this approach, the architectural patterns that enable it, implementation strategies, error handling, and production-hardening techniques that make application-level enforcement reliable at scale.

The Application as Orchestrator

In application-level enforcement, the database stores data but the application orchestrates consistency. Every update path must include synchronization logic. This requires careful architecture—but enables patterns impossible within the database alone.

When to Choose Application Enforcement

Application-level enforcement is not a replacement for database triggers—it's a complementary approach suited to specific scenarios. Understanding when to choose each approach is essential for effective denormalization design.

Triggers vs. Application Enforcement Decision Matrix
Factor	Favor Triggers	Favor Application Enforcement
Update Sources	Multiple sources (app, SQL, tools)	Single application controls all updates
Logic Complexity	Simple cascades and calculations	Complex business rules, conditional logic
Cross-Database	Single database	Multiple databases or services
External Systems	Self-contained updates	Need to call APIs, queues, or caches
Error Handling	All-or-nothing is acceptable	Need retry, partial completion, compensation
Testing	Basic trigger testing sufficient	Complex scenarios need comprehensive tests
Performance Visibility	Database handles optimization	Need fine-grained performance control
Schema Control	Full DDL control	Limited or no trigger support (e.g., some cloud DBs)

Compelling Cases for Application Enforcement

•Cross-Service Synchronization: When denormalized data must be consistent across multiple microservices or databases, triggers can't help—the application must coordinate.
•External Cache Invalidation: Updating a denormalized database value and invalidating a Redis cache in the same operation requires application logic.
•Complex Conditional Logic: If synchronization depends on business state (user tier, feature flags, time of day), application code handles this naturally while SQL becomes unwieldy.
•Async Processing Required: When immediate consistency isn't required and you want to offload work to queues or workers, application code initiates this.
•Third-Party API Integration: Updating denormalized data that also requires notifying external systems (webhooks, partner APIs) demands application orchestration.
•Serverless or NoSQL Databases: Platforms like DynamoDB, Firestore, or serverless PostgreSQL variants may have limited or no trigger support.

Hybrid Approach Often Best

Many production systems use both: database triggers for critical, simple cascades that must never fail, and application enforcement for complex cross-system synchronization. Don't view these as mutually exclusive—use each where it excels.

Architectural Patterns for Application Enforcement

Reliable application-level enforcement requires deliberate architectural design. Several proven patterns help organize synchronization logic in maintainable, testable ways.

Pattern: Domain events signal that something important happened in the business domain. Handlers subscribe to these events and perform synchronization.

Benefits:

Decouples business logic from synchronization
Easy to add new handlers without modifying core code
Natural fit for eventual consistency models
Enables testing of each concern independently

domain_events.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
// Domain Event Pattern for denormalization consistency
 
// Domain event definition
interface DomainEvent {
    eventType: string;
    aggregateId: string;
    occurredAt: Date;
    payload: unknown;
}
 
interface CustomerNameChanged extends DomainEvent {
    eventType: 'CustomerNameChanged';
    payload: {
        customerId: string;
        oldName: string;
        newName: string;
    };
}
 
// Event publisher (typically injected as dependency)
class DomainEventPublisher {
    private handlers = new Map<string, Array<(event: DomainEvent) => Promise<void>>>();
    
    subscribe(eventType: string, handler: (event: DomainEvent) => Promise<void>) {
        const existing = this.handlers.get(eventType) || [];
        this.handlers.set(eventType, [...existing, handler]);
    }
    
    async publish(event: DomainEvent) {
        const handlers = this.handlers.get(event.eventType) || [];
        await Promise.all(handlers.map(h => h(event)));
    }
}
 
// Customer service publishes events
class CustomerService {
    constructor(
        private db: Database,
        private eventPublisher: DomainEventPublisher
    ) {}
    
    async updateCustomerName(customerId: string, newName: string) {
        const customer = await this.db.customers.findById(customerId);
        const oldName = customer.name;
        
        await this.db.customers.update(customerId, { name: newName });
        
        // Publish event - handlers will synchronize denormalized data
        await this.eventPublisher.publish({
            eventType: 'CustomerNameChanged',
            aggregateId: customerId,
            occurredAt: new Date(),
            payload: { customerId, oldName, newName }
        });
    }
}
 
// Handler synchronizes orders table
class OrderDenormalizationHandler {
    constructor(private db: Database) {}
    
    async handle(event: CustomerNameChanged) {
        await this.db.orders.updateMany(
            { customerId: event.payload.customerId },
            { customerName: event.payload.newName }
        );
    }
}
 
// Setup
const publisher = new DomainEventPublisher();
const orderHandler = new OrderDenormalizationHandler(db);
publisher.subscribe('CustomerNameChanged', (e) => orderHandler.handle(e as CustomerNameChanged));

Transactional Strategies

Application-level enforcement must carefully manage transaction boundaries to ensure atomicity. Several strategies exist, each with different consistency and performance characteristics.

Transaction Strategies

•Single Transaction (Strong Consistency): All updates—primary and denormalized—execute in one database transaction. Either all succeed or all fail. Best for critical data but may cause long-held locks.
•Outbox Pattern (Eventual Consistency): Primary update commits with an 'outbox' record describing needed synchronization. A separate process reads the outbox and applies denormalization updates. Guarantees eventual consistency without blocking the main operation.
•Saga Pattern (Distributed): For cross-service synchronization, a saga coordinates multiple services, each updating their own data, with compensation on failure. Complex but necessary for microservices.
•Two-Phase Commit (Rare): Coordinates transactions across multiple databases. Strong consistency but significant performance and availability costs. Rarely used in modern systems.

outbox_pattern.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
// Outbox Pattern for reliable eventual consistency
 
interface OutboxEntry {
    id: string;
    eventType: string;
    payload: string;        // JSON serialized
    createdAt: Date;
    processedAt: Date | null;
    retryCount: number;
}
 
class OutboxBasedSynchronization {
    constructor(
        private db: Database,
        private syncProcessor: SyncProcessor
    ) {}
    
    async updateCustomerName(customerId: string, newName: string): Promise<void> {
        // Single transaction: update + outbox entry
        await this.db.transaction(async (tx) => {
            // Primary update
            await tx.customers.update(customerId, { name: newName });
            
            // Outbox entry for async denormalization
            await tx.outbox.insert({
                id: generateId(),
                eventType: 'SYNC_CUSTOMER_NAME',
                payload: JSON.stringify({ customerId, newName }),
                createdAt: new Date(),
                processedAt: null,
                retryCount: 0
            });
        });
        
        // Main operation completes here - user gets fast response
        // Denormalization happens asynchronously
    }
}
 
// Background processor polls and processes outbox
class OutboxProcessor {
    constructor(private db: Database) {}
    
    async processOutbox(): Promise<void> {
        const entries = await this.db.outbox.findUnprocessed({ limit: 100 });
        
        for (const entry of entries) {
            try {
                await this.processEntry(entry);
                await this.db.outbox.update(entry.id, {
                    processedAt: new Date()
                });
            } catch (error) {
                await this.db.outbox.update(entry.id, {
                    retryCount: entry.retryCount + 1,
                    lastError: error.message
                });
                
                if (entry.retryCount >= 5) {
                    await this.moveToDeadLetter(entry);
                }
            }
        }
    }
    
    private async processEntry(entry: OutboxEntry): Promise<void> {
        const payload = JSON.parse(entry.payload);
        
        switch (entry.eventType) {
            case 'SYNC_CUSTOMER_NAME':
                await this.db.orders.updateMany(
                    { customerId: payload.customerId },
                    { customerName: payload.newName }
                );
                break;
            // ... other event types
        }
    }
}

Choose Consistency Level Deliberately

Strong consistency (single transaction) is simpler but may not scale. Eventual consistency (outbox/saga) scales well but introduces temporary inconsistency windows. Document your consistency guarantees and ensure downstream systems can handle them.

Error Handling and Recovery

Application-level enforcement enables sophisticated error handling that goes beyond trigger capabilities. Proper error handling design is critical for production reliability.

Retry Strategies

•Immediate Retry: For transient failures (connection reset, deadlock), retry immediately with exponential backoff
•Delayed Retry: Queue for later retry when external systems are down
•Dead Letter Queue: After max retries, move to DLQ for manual intervention
•Circuit Breaker: Stop retrying when a downstream system is clearly failing

Compensation Strategies

•Rollback Compensation: Undo primary change when sync fails
•Forward Recovery: Keep trying until sync succeeds (eventual consistency)
•Manual Compensation: Alert operators for manual intervention
•Reconciliation: Accept temporary inconsistency, fix during scheduled reconciliation

error_handling.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
// Comprehensive error handling for sync operations
 
interface RetryConfig {
    maxRetries: number;
    initialDelayMs: number;
    maxDelayMs: number;
    backoffMultiplier: number;
}
 
class ResilientSyncExecutor {
    private readonly defaultConfig: RetryConfig = {
        maxRetries: 5,
        initialDelayMs: 100,
        maxDelayMs: 30000,
        backoffMultiplier: 2
    };
    
    async executeWithRetry<T>(
        operation: () => Promise<T>,
        config: Partial<RetryConfig> = {}
    ): Promise<T> {
        const { maxRetries, initialDelayMs, maxDelayMs, backoffMultiplier } = 
            { ...this.defaultConfig, ...config };
        
        let lastError: Error;
        let delay = initialDelayMs;
        
        for (let attempt = 1; attempt <= maxRetries; attempt++) {
            try {
                return await operation();
            } catch (error) {
                lastError = error;
                
                // Categorize error for appropriate handling
                if (this.isNonRetryable(error)) {
                    throw new NonRetryableError(
                        `Permanent failure on attempt ${attempt}: ${error.message}`,
                        { cause: error }
                    );
                }
                
                if (attempt < maxRetries) {
                    const jitter = Math.random() * 0.3 * delay;
                    const waitTime = Math.min(delay + jitter, maxDelayMs);
                    
                    console.log(`Attempt ${attempt} failed, retrying in ${waitTime}ms`);
                    await this.sleep(waitTime);
                    
                    delay *= backoffMultiplier;
                }
            }
        }
        
        throw new MaxRetriesExceededError(
            `Failed after ${maxRetries} attempts`,
            { cause: lastError }
        );
    }
    
    private isNonRetryable(error: Error): boolean {
        // Validation errors, not-found, permissions - won't succeed on retry
        const nonRetryableCodes = [
            'INVALID_INPUT',
            'NOT_FOUND',
            'PERMISSION_DENIED',
            'SCHEMA_VIOLATION'
        ];
        
        return nonRetryableCodes.includes((error as any).code);
    }
    
    private sleep(ms: number): Promise<void> {
        return new Promise(resolve => setTimeout(resolve, ms));
    }
}
 
// Usage with saga-style compensation
class CustomerUpdateSaga {
    constructor(
        private db: Database,
        private syncExecutor: ResilientSyncExecutor,
        private alertService: AlertService
    ) {}
    
    async updateCustomerName(customerId: string, newName: string): Promise<void> {
        // Step 1: Primary update (must succeed)
        const oldName = await this.db.customers.findById(customerId);
        await this.db.customers.update(customerId, { name: newName });
        
        try {
            // Step 2: Sync to orders (with retry)
            await this.syncExecutor.executeWithRetry(async () => {
                await this.db.orders.updateMany(
                    { customerId },
                    { customerName: newName }
                );
            });
            
            // Step 3: Sync to external CRM (with retry)
            await this.syncExecutor.executeWithRetry(async () => {
                await this.externalCRM.updateContact(customerId, { name: newName });
            });
            
        } catch (error) {
            if (error instanceof MaxRetriesExceededError) {
                // Compensation: revert primary change
                await this.db.customers.update(customerId, { name: oldName.name });
                await this.alertService.critical(
                    'Customer name update failed after retries - reverted',
                    { customerId, error }
                );
            }
            throw error;
        }
    }
}

Log Everything

When handling sync failures, comprehensive logging is essential. Log the operation, all retry attempts, final outcome, and any compensation actions. This enables debugging, audit trails, and detection of systematic issues.

Cross-Service Synchronization

In microservices architectures, denormalized data often spans service boundaries. Each service owns its database, but needs consistent views of data from other services. This is one of the most compelling use cases for application-level enforcement.

Cross-Service Sync Patterns

•Event-Driven Sync: Services publish domain events to a message bus; other services subscribe and update their denormalized copies. Eventual consistency, highly decoupled.
•API-Based Sync: Services call other services' APIs to push or pull data changes. Synchronous but creates coupling and latency.
•Change Data Capture (CDC): Database changes stream to a message system (e.g., Debezium); other services consume and sync. Reliable but requires infrastructure.
•Shared Cache Layer: Services read denormalized data from a shared cache (Redis) that's updated by the owning service. Fast reads, single source of truth for cache.

event_driven_sync.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
// Event-Driven Cross-Service Synchronization
 
// Customer Service (source of truth for customer data)
class CustomerService {
    constructor(
        private db: CustomerDatabase,
        private messageBus: MessageBus
    ) {}
    
    async updateCustomerName(customerId: string, newName: string): Promise<void> {
        const customer = await this.db.customers.update(customerId, { name: newName });
        
        // Publish event for other services
        await this.messageBus.publish('customer.events', {
            eventType: 'CustomerUpdated',
            eventId: generateEventId(),
            timestamp: new Date().toISOString(),
            payload: {
                customerId,
                changes: {
                    name: { previous: customer.previousName, current: newName }
                }
            }
        });
    }
}
 
// Order Service (has denormalized customer data)
class OrderServiceEventHandler {
    constructor(
        private db: OrderDatabase,
        private eventStore: ProcessedEventStore  // For idempotency
    ) {}
    
    async handleCustomerUpdated(event: CustomerUpdatedEvent): Promise<void> {
        // Idempotency check - don't process same event twice
        if (await this.eventStore.isProcessed(event.eventId)) {
            console.log(`Event ${event.eventId} already processed, skipping`);
            return;
        }
        
        try {
            const { customerId, changes } = event.payload;
            
            // Update denormalized customer data in orders
            if (changes.name) {
                await this.db.orders.updateMany(
                    { customerId },
                    { 
                        customerName: changes.name.current,
                        denormSyncedAt: new Date(),
                        denormSourceEventId: event.eventId
                    }
                );
            }
            
            // Mark event as processed
            await this.eventStore.markProcessed(event.eventId, {
                processedAt: new Date(),
                affectedRows: await this.db.orders.count({ customerId })
            });
            
        } catch (error) {
            // Don't mark as processed - will be retried
            console.error(`Failed to process event ${event.eventId}:`, error);
            throw error;  // Let message bus handle retry
        }
    }
}
 
// Message consumer setup
class MessageConsumer {
    constructor(
        private messageBus: MessageBus,
        private handler: OrderServiceEventHandler
    ) {}
    
    async start() {
        await this.messageBus.subscribe('customer.events', async (event) => {
            switch (event.eventType) {
                case 'CustomerUpdated':
                    await this.handler.handleCustomerUpdated(event);
                    break;
                // ... other event types
            }
        });
    }
}

Event Ordering and Idempotency

Cross-service events may arrive out of order or be delivered multiple times. Always implement idempotency (check if event was already processed) and consider event ordering (use timestamps or version numbers to handle out-of-order delivery).

External System Integration

Denormalization often extends beyond the database into caches, search indexes, CDNs, and third-party systems. Application-level enforcement handles these integrations that database triggers cannot reach.

Common External System Sync Targets
System Type	Sync Purpose	Consistency Model	Failure Handling
Redis Cache	Fast read access to denormalized data	Eventual (TTL-based or explicit invalidation)	Accept stale reads; retry invalidation
Elasticsearch	Full-text search over denormalized documents	Eventual (async indexing)	Queue for reindex; tolerate search lag
CDN	Static content with embedded data	Eventual (cache purge)	Purge on update; accept stale during propagation
Analytics DB	Denormalized fact tables for reporting	Eventual (ETL process)	Retry ETL; accept reporting delay
Third-Party CRM	Customer data sync with sales tools	Eventual (API calls)	Queue updates; alert on persistent failures

external_sync.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
// Multi-System Synchronization Orchestrator
 
interface SyncTarget {
    name: string;
    priority: number;  // Lower = higher priority
    critical: boolean; // If true, failures block operation
    sync: (data: SyncData) => Promise<void>;
}
 
class MultiSystemSyncOrchestrator {
    private targets: SyncTarget[] = [];
    
    constructor(
        private db: Database,
        private cache: RedisClient,
        private search: ElasticsearchClient,
        private crm: CRMClient,
        private alertService: AlertService
    ) {
        this.registerTargets();
    }
    
    private registerTargets() {
        this.targets = [
            {
                name: 'cache',
                priority: 1,
                critical: false,  // Cache miss is acceptable
                sync: async (data) => {
                    await this.cache.del(`customer:${data.customerId}`);
                    await this.cache.del(`customer:${data.customerId}:orders`);
                }
            },
            {
                name: 'search',
                priority: 2,
                critical: false,  // Search can lag
                sync: async (data) => {
                    await this.search.update('customers', data.customerId, {
                        name: data.newName,
                        updatedAt: new Date()
                    });
                }
            },
            {
                name: 'crm',
                priority: 3,
                critical: false,  // CRM can be eventually consistent
                sync: async (data) => {
                    await this.crm.updateContact(data.customerId, {
                        displayName: data.newName
                    });
                }
            }
        ];
    }
    
    async syncCustomerUpdate(customerId: string, newName: string): Promise<SyncResult> {
        const syncData = { customerId, newName, timestamp: new Date() };
        const results: SyncResult = { succeeded: [], failed: [] };
        
        // Sort by priority
        const orderedTargets = [...this.targets].sort((a, b) => a.priority - b.priority);
        
        for (const target of orderedTargets) {
            try {
                await target.sync(syncData);
                results.succeeded.push(target.name);
                
            } catch (error) {
                results.failed.push({ target: target.name, error: error.message });
                
                if (target.critical) {
                    // Critical target failed - abort remaining syncs
                    this.alertService.critical(`Critical sync failed: ${target.name}`, {
                        customerId, error
                    });
                    break;
                } else {
                    // Non-critical - log and queue for retry
                    await this.queueForRetry(target.name, syncData);
                    this.alertService.warning(`Non-critical sync failed: ${target.name}`, {
                        customerId, error
                    });
                }
            }
        }
        
        return results;
    }
    
    private async queueForRetry(targetName: string, data: SyncData): Promise<void> {
        await this.db.syncRetryQueue.insert({
            target: targetName,
            data: JSON.stringify(data),
            createdAt: new Date(),
            retryAfter: new Date(Date.now() + 60000),  // Retry in 1 minute
            attempts: 0
        });
    }
}

Testing Application Enforcement

Application-level enforcement code must be rigorously tested. Unlike triggers that are tested through SQL, application sync code benefits from standard unit and integration testing practices.

Testing Strategy for Sync Code

•Unit Tests: Test sync logic functions in isolation with mocked dependencies. Verify correct data transformations and update calls.
•Integration Tests: Test full sync flows against real (test) databases. Verify that source changes correctly propagate to all denormalized locations.
•Failure Injection Tests: Simulate database failures, network errors, and partial completions. Verify retry logic, compensation, and alerting.
•Concurrency Tests: Run multiple sync operations concurrently to detect race conditions and deadlocks.
•Idempotency Tests: Execute the same sync operation multiple times; verify the end state is correct and no duplicate updates occur.
•End-to-End Tests: Test complete user scenarios that trigger sync; verify all downstream systems have consistent data.

sync_tests.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
// Comprehensive test suite for application-level sync
 
describe('CustomerNameSynchronization', () => {
    let db: TestDatabase;
    let sync: CustomerSynchronizer;
    
    beforeEach(async () => {
        db = await TestDatabase.create();
        sync = new CustomerSynchronizer(db);
        
        // Seed test data
        await db.customers.insert({ id: 'cust-1', name: 'Original Name' });
        await db.orders.insert({ id: 'order-1', customerId: 'cust-1', customerName: 'Original Name' });
        await db.orders.insert({ id: 'order-2', customerId: 'cust-1', customerName: 'Original Name' });
    });
    
    afterEach(async () => {
        await db.destroy();
    });
    
    describe('successful sync', () => {
        it('updates all denormalized copies', async () => {
            await sync.updateCustomerName('cust-1', 'New Name');
            
            const customer = await db.customers.findById('cust-1');
            const orders = await db.orders.find({ customerId: 'cust-1' });
            
            expect(customer.name).toBe('New Name');
            expect(orders.every(o => o.customerName === 'New Name')).toBe(true);
        });
        
        it('updates timestamp metadata', async () => {
            const before = new Date();
            await sync.updateCustomerName('cust-1', 'New Name');
            
            const orders = await db.orders.find({ customerId: 'cust-1' });
            expect(orders.every(o => o.denormUpdatedAt >= before)).toBe(true);
        });
    });
    
    describe('idempotency', () => {
        it('produces same result when called multiple times', async () => {
            await sync.updateCustomerName('cust-1', 'New Name');
            await sync.updateCustomerName('cust-1', 'New Name');
            await sync.updateCustomerName('cust-1', 'New Name');
            
            const orders = await db.orders.find({ customerId: 'cust-1' });
            expect(orders.length).toBe(2);  // No duplicates created
            expect(orders.every(o => o.customerName === 'New Name')).toBe(true);
        });
    });
    
    describe('failure handling', () => {
        it('rolls back on order sync failure', async () => {
            // Inject failure on order update
            db.orders.updateMany = jest.fn().mockRejectedValue(new Error('DB Error'));
            
            await expect(sync.updateCustomerName('cust-1', 'New Name'))
                .rejects.toThrow('DB Error');
            
            // Verify customer was rolled back
            const customer = await db.customers.findById('cust-1');
            expect(customer.name).toBe('Original Name');
        });
        
        it('retries transient failures', async () => {
            let callCount = 0;
            db.orders.updateMany = jest.fn().mockImplementation(async () => {
                callCount++;
                if (callCount < 3) throw new TransientError('Connection reset');
                return { affected: 2 };
            });
            
            await sync.updateCustomerName('cust-1', 'New Name');
            
            expect(callCount).toBe(3);  // Retried twice, succeeded on third
            const customer = await db.customers.findById('cust-1');
            expect(customer.name).toBe('New Name');
        });
    });
    
    describe('concurrency', () => {
        it('handles concurrent updates correctly', async () => {
            // Run multiple concurrent updates
            await Promise.all([
                sync.updateCustomerName('cust-1', 'Name A'),
                sync.updateCustomerName('cust-1', 'Name B'),
                sync.updateCustomerName('cust-1', 'Name C'),
            ]);
            
            // All denormalized copies should have the same value
            const customer = await db.customers.findById('cust-1');
            const orders = await db.orders.find({ customerId: 'cust-1' });
            
            expect(orders.every(o => o.customerName === customer.name)).toBe(true);
        });
    });
});

Summary: Application Enforcement

Application-level enforcement is a powerful complement to database triggers, enabling consistency maintenance in scenarios that triggers cannot handle. Let's consolidate the key insights:

Key Takeaways

•Choose application enforcement for complex logic, cross-service sync, external systems, and when triggers aren't available or sufficient.
•Use established patterns: Domain events, repositories, and unit of work provide maintainable structures for sync logic.
•Choose transaction strategy deliberately: Single transactions for strong consistency; outbox/saga for scalable eventual consistency.
•Handle errors comprehensively: Implement retry with backoff, compensation on failure, and alerting for persistent issues.
•Design for cross-service scenarios: Use event-driven architecture with idempotency and ordering guarantees.
•Integrate external systems: Cache, search, and third-party systems need sync too—use priority-based orchestration.
•Test rigorously: Unit, integration, failure injection, concurrency, and idempotency tests are all essential.

What's Next:

Both triggers and application enforcement maintain consistency at write time. But what about scenarios where perfect synchronization isn't possible or practical? The next page explores batch synchronization—scheduled processes that detect and correct inconsistencies, providing a safety net for eventual consistency systems.

Application Enforcement Mastery Achieved

You now understand when and how to implement application-level consistency enforcement for denormalized data. This approach enables handling of complex, cross-system scenarios that database triggers cannot address—a critical capability for modern distributed systems.