NestJS + TypeORM: Managing In‑Flight Requests After a Database Restore

The Core Challenge

TypeORM and NestJS are stateless regarding external database events. Because a pg_dump or similar restore happens outside the application layer, TypeORM cannot natively detect if a specific request was "in-flight" during the backup window. Furthermore, since the application is restarted against the restored instance, all in-memory request contexts are wiped; requests cannot "resume" in the same process—they must be retried by the client or a queue manager.

Detection and Prevention Strategies

To manage consistency and prevent the processing of stale or duplicate requests after a restore, implement the following patterns:

1. Idempotency Keys for Request Tracking

The application cannot detect a "backup window" retrospectively. Instead, you must ensure that any request that was partially processed before the dump is not duplicated after the restore. Implement Idempotency Keys (passed in headers by the client):

• Store the idempotency key and the resulting response in a persistent store (e.g., Redis) with a TTL.
• Before executing a TypeORM transaction, check if the key exists.
• If the database was restored to a point before the key was recorded, the system will treat the retry as a new request, which is the correct behavior for a restore event.

2. Graceful Shutdown (Drain Period)

To minimize the number of in-flight requests that are interrupted during the restore process, use NestJS shutdown hooks to implement a drain period. This prevents the "hard kill" of transactions.

// main.ts
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  // Enable shutdown hooks to handle SIGTERM
  app.enableShutdownHooks(); 
  await app.listen(3000);
}

When the orchestration layer (e.g., Kubernetes) sends a SIGTERM, NestJS will stop accepting new connections and attempt to finish active requests before the process exits, ensuring fewer requests are left in an ambiguous state during the database downtime.

Implementation Summary

  

    

      
Goal
      
Mechanism
      
Responsibility
    
  
  

    

      
Detect In-Flight Requests
      
Idempotency Keys / Request Logs
      
Application Layer
    
    

      
Prevent Stale Writes
      
Database Transactions (ACID)
      
TypeORM / Postgres
    
    

      
Minimize Interruptions
      
enableShutdownHooks()
      
NestJS Framework
    
  


Verification Steps

  
Simulate Restore: Trigger a database restore and restart the NestJS service.
  
Test Idempotency: Send a request, simulate a crash/restore, and replay the same request with the same idempotency key to verify the system handles it without duplicating data.
  
Verify Drain: Send a long-running request and trigger a SIGTERM; verify the request completes before the process terminates.


Diagnostic Detail Needed: Are these in-flight requests primarily synchronous HTTP calls or asynchronous background jobs (e.g., BullMQ)? The strategy for replaying failed background jobs differs significantly from HTTP request retries.