On October 19 2025 AWS experienced an outage that lasted over a day, 10 days later we finally got the root cause analysis and we know exactly what caused the DNS to fail0:00 Summary 5:30 How did Dynamo lost its DNS?13:41 EC2 Errors 16:16 Network Load Balancer ErrorsRCA here https://aws.amazon.com/message/101925/

There are cases where the backend may need to close the connection to prevent unexpected situations, prevent bad actors or simply just free up resources. Closing a connection gracefully allows clients and backends to clean up and finish any pending requests. 

In this episode of the backend engineering show I discuss graceful connections in both HTTP/1.1 via the connection header and HTTP/2 via the GOAWAY frame. 

• 0:00 Intro
• 4:58 Why shutdown connection? 
• 6:46 HTTP/1.1 Graceful shutdown
• 12:26 Cost of HTTP/2 
• 17:40 HTTP/2 GoAWAY frame
• 23:40 Summary

Links

https://www.youtube.com/watch?v=fVKPrDrEwTI&t=1s 

https://chromium.googlesource.com/chromium/src/net/%2B/master/socket/client_socket_pool_manager.cc#76

https://issues.chromium.org/issues/40555364

https://issues.chromium.org/issues/40501721

Postgres 18 has been released with many exciting features such as UUIDv7, Over explain module, composite index skip scans, and the most anticipated asynchronous IO with worker and io_uring mode which I uncover in this show. Hope you enjoy it

0:00 Intro

1:30 Synchronous vs Asynchronous calls

3:00 Synchronous IO

6:30 Asynchronous IO

10:00 Postgres 17 synchronous io

17:20 The challenge of Async IO in Postgres 18

20:00 io_method worker23:00

io_method io_uring

29:30 io_method sync

31:08 Async IO isn’t done! 3

1:30 Support for backend writers

32:36 Improve worker io_method

33:00 direct io support

37:00 Summary

Fundamentals of Operating Systems Course https://oscourse.winktls is brilliant.TLS encryption/decryption often happens in userland. While TCP lives in the kernel. With ktls, userland can hand the keys to the kernel and the kernel does crypto. When calling write, the kernel encrypts the packet and send it to the NIC.When calling read, the kernel decrypts the packet and handed it to the userspace. This mode still taxes the host’s CPU of course, so there is another mode where the kernel offloads the crypto to the NIC device! Host CPU becomes free. Incoming packets to the NIC are decrypted in device before they are DMAed to the kernel. outgoing packets are encrypted before they leave the NIC to the network.ktls still need handshake to happen in userspace. There is also enabling zerocopy in some cases (now that kernel has context) Deserves a video. So much good stuff.0:00 Intro2:00 Userspace SSL Libraries 3:00 ktls 6:00 Kernel Encrypts/Decrypts (TLS_SW)8:20 NIC offload mode (TLS_HW)10:15 NIC does it all (TLS_HW_RECORD)12:00 Write TX Example13:50 Read RX Example17:00 Zero copy (sendfile)https://docs.kernel.org/networking/tls-offload.html

If you are bored of contemporary topics of AI and need a breather, I invite you to join me to explore a mundane, fundamental and earthy topic.

The CPU.

A reading of my substack article https://hnasr.substack.com/p/the-beauty-of-the-cpu

This new PostgreSQL 17 feature is game changer. They know can combine IOs when performing sequential scan.

Grab my database course

https://courses.husseinnasser.com

No technical video today, just talking about the idea of discipline and consistency.

Fundamentals of Operating Systems Course

This video is an overview of how the operating system kernel does socket management and the different data structures it utilizes to achieve that.

timestamps

0:00 Intro

1:38 Socket vs Connections

7:50 SYN and Accept Queue

18:56 Socket Sharding

23:14 Receive and Send buffers

27:00 Summary

Polling is the ability to interrogate a backend to see if a piece of information is ready. It can introduce a chatty system and as a result long polling was born. In this video I explain the beauty of this design pattern and how we can push it to its limit.

You get better as a software engineer when you go through these stages.

0:00 Intro 

1:15 Understand a technology

7:07 Articulate how it works

15:30 Understand its’ limitations

19:48 Try to build something better

27:45 Realize what you built also has limitations

32:48 Appreciate the original tech as is

 We use technologies all the time without knowing how it works. And it is ok not knowing how things work if interests isn’t there. But when there is interest to understand how something works, pursue it. It feels good when you understand how something works because you work better with it, you swim with the tide instead of against it. 

When I learned how TCP/IP work..  you would appreciate every connection request, how you read requests. You will ask questions,

 what is my code doing here? 

When exactly I’m creating connections?

When am I reading from the connection? 

Is it safe to share connections?

This one is not easy, you might think you understand something until you try to explain how it works. If you find yourself using jargon you probably don’t understand and you just try to impress others. Have you seen people who want to talk about something to show they understand it? It’s the opposite. Try to truly articlate how it works, you will really understand it , back to 1.

I thought I understand how backend reads requests until I tried to speak to it. 

Once 1,2 are done you will truly understand the tech, now you are confidant, you are excited about the tech and you will truly see when you can use the tech to its full potential and also know the weak points of the tech where it breaks, this happens a lot with TCP/IP. We know tcps limitations. 

This one is optional and can be skipped, but attempting to design or building something better then the tech because you know the limitations will truly reveal how you became better. But the challenge here is the ego, you might understand the limitations but you problem is thinking that what you will build is flawless. This step must be proceed with caution. 

Dust settles.. this step hurts, and you may take a while to realize it, but whatever you build will have flaws… and when you realize this it is when you get better as an engineer. 

This is when you are back full circle you are back to the first stage, look at the technology and understand it but don’t judge it.. just know the limitations and its strength and flow with it. Stop fighting and instead build around a tech, does that mean you shouldn’t build anything new, of course not. Go build, but don’t stress around making something better to defeat existing tech. But actually build it for building it.