The Backend Engineering Show with Hussein Nasser

Background writing is a process that writes dirty pages in shared buffer to the disk (well goes to the OS file cache then get flushed to disk by the OS) I go into this process in this video

The podcast discusses the concept of memory fragmentation and its impact on performance. It explores the structure of DDR RAM and the cost of accessing different rows. The podcast also delves into the use of virtual memory and the challenges of TLB mess. It highlights the cost of memory fragmentation and retrieval and the differences between hard drive and RAM access.

Explore the hidden costs of sending a request from the frontend to the backend, including performance implications and challenges in determining backend capacity. Dive into the intricacies of handling requests in the backend, such as establishing connections, data decryption, parsing requests, and hidden complexities. Understand the process of parsing and decoding a request in backend engineering, including challenges with binary protocols, the cost of serialization and deserialization, importance of byte representation, and potential for splitting CPU-heavy tasks.

Fundamentals of Database Engineering udemy course (link redirects to udemy with coupon) https://database.husseinnasser.com Why create Index blocks writes In this video I explore how create index, why does it block writes and how create index concurrently work and allow writes. 0:00 Intro 1:28 How Create Index works 4:45 Create Index blocking Writes 5:00 Create Index Concurrently

The podcast discusses the increasing popularity of HTTP/3, compares it to HTTP/1 and HTTP/2 in terms of cost, and explores the differences in working with HTTP1 and HTTP2 in the backend. The variances between HTTP, HTTP2, and QUIC protocols are also explored, along with the structure and potential of HTTP/3.

The Encrypted Client Hello or ECH is a new RFC that encrypts the TLS client hello to hide sensitive information like the SNI. In this video I go through pros and cons of this new rfc. 0:00 Intro 2:00 SNI 4:00 Client Hello 8:40 Encrypted Client Hello 11:30 Inner Client Hello Encryption 18:00 Client-Facing Outer SNI 21:20 Decrypting Inner Client Hello 23:30 Disadvantages 26:00 Censorship vs Privacy ECH https://blog.cloudflare.com/announcing-encrypted-client-hello/ https://chromestatus.com/feature/6196703843581952

From the frontend through the kernel to the backend processWhen we send a request to a backend most of us focus on the processing aspect of the request which is really just the last step. There is so much more happening before a request is ready to be processed, most of this step happens in the Kernel. I break this into 6 steps, each step can theoretically be executed by a dedicated thread or process. Pretty much all backends, web servers, proxies, frameworks and even databases have to do all these steps and they all do choose to do it differently. Grab my backend performance course https://performance.husseinnasser.com 0:00 Intro 3:50 What is a Request? 10:14 Step 1 - Accept  21:30 Step 2 - Read 29:30 Step 3 - Decrypt 34:00 Step 4 - Parse 40:36 Step 5 - Decode 43:14 Step 6 - Process Medium article https://medium.com/@hnasr/the-journey-of-a-request-to-the-backend-c3de704de223

In a wonderful blog, Kyle explores the pains he faced managing a Postgres instance for a startup he works for and how enabling partitioning sigintfically created wait events causing the backend and subsequently NGINX to through 500 errors. We discuss this in this video/podcast https://www.kylehailey.com/post/postgres-partition-pains-lockmanager-waits

WebTransport is a cutting-edge protocol framework designed to support multiplexed and secure transport over HTTP/2 and HTTP/3. It brings together the best of web and transport technologies, providing an all-in-one solution for real-time, bidirectional communication on the web. Watch full episode (subscribers only) https://spotifyanchor-web.app.link/e/cTSGkq5XuAb

fsync is a linux system call that flushes all pages and metadata for a given file to the disk. It is indeed an expensive operation but required for durability especially for database systems. Regular writes that make it to the disk controller are often placed in the SSD local cache to accumulate more writes before getting flushed to the NAND cells. However when the disk controller receives this flush command it is required to immediately persist all of the data to the NAND cells. Some SSDs however don't do that because they don't trust the host and no-op the fsync. In this video I explain this in details and go through details on how postgres provide so many options to fine tune fsync 0:00 Intro 1:00 A Write doesn’t write 2:00 File System Page Cache 6:00 Fsync 7:30 SSD Cache 9:20 SSD ignores the flush 9:30 15 Year old Firefox fsync bug 12:30 What happens if SSD loses power 15:00 What options does Postgres exposes? 15:30 open_sync (O_SYNC) 16:15 open_datasync (O_DSYNC) 17:10 O_DIRECT 19:00 fsync 20:50 fdatasync 21:13 fsync = off 23:30 Don’t make your API simple 26:00 Database on metal?