As software engineers, it’s always better to understand the internals of the systems we use. Knowing how things work under the hood gives us deeper insight, helps us debug smarter, and makes us better at designing reliable applications.

In this blog, I’ll share the internals of Redis - the parts that finally “clicked” for me while learning. My goal is simple: to help you build a better mental model of Redis so you can use it more effectively in your own projects.

Redis is an in‑memory data structure store that can be used as a database, cache, message broker, and more. Because it keeps data in RAM, reads and writes are extremely fast.

A common surprise is that Redis is single threaded. That means the core server processes commands on one thread. That raises an obvious question: if two clients send requests at the same time, doesn’t one have to wait for the other? Wouldn’t multithreading give better parallelism?

Technically, requests are handled sequentially. But in practice this isn’t a bottleneck for Redis. Accessing RAM takes nanoseconds, so simple commands like SET or GET complete extremely quickly. Even if thousands of requests are queued, the single thread can process them in a tiny fraction of a second. Introducing multithreading would add context switches, locks, and synchronization overhead that often slow things down more than they help.

Redis uses IO multiplexing: one thread watches many I/O sources and reacts only when they’re ready. On Linux, Redis uses the epoll system call to get notified when sockets have activity.

The Redis server loop performs two main tasks: it accepts new connections, which can be from your backend services or redis-cli, and it executes commands received on existing connections, such as GET or SET.

When the server starts, it registers sockets with epoll. The main thread runs an event loop that waits for epoll to indicate which sockets are ready. When epoll reports an event, Redis handles it right away, such as accepting a connection or reading and executing a command. If a client is connected but idle, Redis doesn't wait for that client; it just keeps processing other ready events. This event‑driven architecture keeps the server responsive without the complexity of many threads.

You can think of Redis’s main() function as an infinite loop that listens for epoll events and dispatches them to a handler. Because commands are executed one at a time on the main thread, each operation is atomic: Redis won’t context switch in the middle of a command and start another.

When two clients increment the same counter using INCR page_views, Client A sends INCR page_views, and Client B sends INCR page_views.

Redis guarantees one increment completes before the next starts. The counter will go 10 → 11 → 12, never lose an update.

Conclusion

Redis’s speed isn’t magic - it’s the result of a deliberate, simple design: keep data in memory, use an event loop driven by epoll, and avoid the complexity of multithreading where it would add overhead. Good engineering often comes from simplifying the system and removing unnecessary components, not from adding complexity for its own sake.

As a backend developer, grasping how data travels across a network is essential for creating robust, efficient, and scalable applications. The OSI (Open Systems Interconnection) Model is a fundamental framework that breaks down network communication into seven distinct layers. Each layer has a specific role, ensuring data is transferred accurately and reliably between devices.

In this guide, we'll explore the OSI Model from a backend developer's perspective, using the example of sending an email. By following data through the OSI layers, you'll gain insight into the complex process behind network communication.

The Seven Layers of the OSI Model

The OSI Model divides communication into seven layers:

1. Application Layer

2. Presentation Layer

3. Session Layer

4. Transport Layer

5. Network Layer

6. Data Link Layer

7. Physical Layer

Let's see how data flows through each layer.

Scenario: Sending an Email

Step 1: Application Layer (Layer 7)

Imagine a boyfriend sending an email to his girlfriend. He opens his email app, writes the message, and hits ‘send.’ At this stage, the data is at the application layer. The app uses SMTP (Simple Mail Transfer Protocol) to format and send the email across the network.

Step 2: Presentation Layer (Layer 6)

The presentation layer translates data into a format both devices understand. It may compress or encrypt the email for efficiency and security, ensuring the data is ready for the next step.

Step 3: Session Layer (Layer 5)

The session layer sets up, maintains, and manages the communication session. It keeps the connection open during the transfer and handles synchronization.

Step 4: Transport Layer (Layer 4)

The data reaches the transport layer, where it’s divided into smaller segments. This segmentation allows for efficient management and error correction. TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) ensures error-checking, flow control, and reliable data transfer.

Step 5: Network Layer (Layer 3)

The network layer breaks segments into packets and adds the IP (Internet Protocol) address, routing the email correctly through the network.

Step 6: Data Link Layer (Layer 2)

The data link layer packages data into frames, including physical addresses (MAC addresses) of the sender and receiver. It ensures error detection during transmission.

Step 7: Physical Layer (Layer 1)

Finally, the data reaches the physical layer, converting it into a bitstream of 1s and 0s. This raw data is transmitted through the physical medium, like cables or Wi-Fi.

Receiving the Email

On the girlfriend's computer, the process reverses:

1. The physical layer receives the bitstream, converts it into frames, and passes it to the data link layer.

2. The data link layer reassembles frames into packets for the network layer.

3. The network layer assembles packets into segments for the transport layer.

4. The transport layer reassembles segments into the full email.

5. The session layer manages session closure.

6. The presentation layer decompresses or decrypts the data.

7. The application layer delivers the email to the app for reading.

Why Backend Developers Should Care

Understanding the OSI Model helps you design efficient, scalable, and secure systems:

• Data Handling: Optimize performance and manage large data effectively.

• Networking Protocols: Troubleshoot and implement solutions by understanding protocol layers.

• Security: Identify vulnerabilities and secure applications, like encryption at the presentation layer.

• Scalability: Make informed decisions on load balancing and network optimization.

Conclusion

The OSI Model is crucial for backend development, providing a clear structure for understanding data flow over networks. By familiarizing yourself with each layer, you can design, optimize, and secure your applications more effectively. Keep the OSI Model in mind as a guide to navigate the complexities of networking in backend development.