Fun fact: Redis, or any database. does not just stop when you hit `Ctrl+C` or when the OS decides to shut down. Databases need to handle termination with extreme care.
This happens by trapping operating system signals like `SIGINT` and `SIGTERM` to ensure that active client commands finish executing and a final snapshot is safely persisted to disk before it says goodbye.
Today, we dive into the source code of Redis to look at how production-grade databases implement graceful shutdown using signal handling.
This is the 19th video in the Redis Internals series. Like always, we keep our focus on execution and not just theory, looking closely at how an open-source database coordinates with the operating system kernel to maintain data integrity and data consistency during its final moments.
In the video, I talk about standard POSIX signals (`SIGINT`, `SIGTERM`, and even edge-case signals like `SIGSEGV`), how native processes trap these interrupts, and the critical problem of preventing abrupt connection termination
We also dive directly into the Redis source code to see where it registers its signal handlers, and then we re-implement this exact graceful termination routine from scratch in Go.
By the way, 19 videos are now live:
1. Why Single-Threaded Redis Is Fast
2. Writing a TCP Echo Server
3. Wire Protocols
4. Implementing RESP
5. Implementing PING
6. Understanding Event Loops
7. Implementing Event Loops
8. Implementing GET, SET, and TTL
9. Implementing DEL, EXPIRE, and Cleanup
10. Evictions and Implementing first-eviction
11. Implementing Command Pipelining
12. Implementing AOF Persistence
13. Objects, Encodings, and Implementing INCR
14. Implementing INFO and allkeys-random Eviction
15. The Approximated LRU Algorithm
16. Implementing the Approx LRU Algorithm
17. How Redis Caps Its Memory Usage
18. How and Why Redis Overrides Malloc
19. Graceful Shutdown using Signal Handling
Hope this helps you better understand database internals and spark that engineering curiosity.
Give it a watch.
we had an incident because we migrated traffic to a brand new s3 bucket.
our millions of servers instantly crushed the new bucket’s partitions and started getting slammed with 5xx errors