DEV Community: Alexey Shevelyov

It Has Been a While. We Need to Talk. Real Talk.

Alexey Shevelyov — Sat, 23 Aug 2025 08:33:50 +0000

We’ve all had times when work doesn’t line up with life.

You give your best, you bend over backwards, you try to make it fit. Sometimes it works for a while, sometimes it doesn’t.

And there’s nothing wrong with that.

Everyone has their own reasons, their own battles, and respect to the people who keep pushing through.

But there comes a point where the weight is too much. Family, health, or just life outside of work can pull harder than any job allows. And when that happens, you realize it’s time to play your hand in a different way.

Companies are built to get results. Their focus is deadlines, goals, and numbers. Smaller ones can sometimes show real care for people. In big or fast-growing ones, even if they try, it’s easy for people to get lost in the scale.

I used to think managers were the problem. Over time I saw it differently. Most aren’t bad — they’re just doing what they signed up for, measured on what the company values. Some truly care, but if I had to bet, most are simply doing what the business asks, not what you personally need.

It’s not personal. It’s just the way the system works.

That’s why even when you give everything, the moment you slip — because of something real, something human — there’s often no room for it.

Your focus drops, stress builds, you stop engaging the same way.

Instead of support, you feel pressure.
Instead of understanding, you get judged.

That doesn’t mean you’re weak. It means you’re human.

When you hit that point, the choice is yours. None of the options are easy, but they belong to you. You can look for a better place. You can try to build something of your own. Or you can take small steps — learning, planning, testing new paths while you keep things steady.

Whatever it looks like, the goal is to move toward a life and work that actually fit you.

I’ve seen this truth in small moments.

Once I had a call with a Verizon rep — we ended up real-talking for a few minutes. I even played some guitar, made her day, and felt her smile through the phone.

Another time I spoke with a healthcare rep, a former 911 dispatcher who had switched jobs and was happier than ever.

I always try to praise good reps when I meet them — so they feel recognized. Those little things matter. Add them up, and they make up our lives.

What I’ve learned is this: people often want to show what they’re going through. Most of the time, no one really listens. And when someone finally does, even for a minute, it feels lighter.

I needed that reminder too.

So I’m opening this up. No need for long stories or private details. Just a simple line about how you’re hanging in there, or what you’re dreaming about, can make a difference.

I’ll read and respond to every one. I’ve stressed more than I should have, and I don’t want you to.

If you want a simple way to share, here’s a format you can use:

Where I’m at right now
What’s weighing on me
What I’m hoping or dreaming about
One thing helping me hang in there

Example:

Where I’m at right now (ex. Feeling stuck in a job that drains me).
What’s weighing on me (ex. Long hours, no recognition).
What I’m hoping or dreaming about (ex. Starting my own thing, even small).
One thing helping me hang in there (ex. My kids — they remind me why I keep moving).

Life is short.

Too short to stay in a role that drains you, or to carry stress that eats you alive. There are no shortcuts. Real growth takes real time and real experience.

Any day above the ground is a good day.
(Scarface)

Don’t waste it. Appreciate it. Make it count.

One truth always holds:

The cards don’t define you. It’s how you play your hand.

Till the next time my people.

The Unstoppable Wave of Misdirected Mobile Notifications and Why It Matters

Alexey Shevelyov — Thu, 15 Feb 2024 16:14:15 +0000

Recently, I got a new phone number from a wireless network operator, only to find myself in the middle of someone else's unresolved business with Spectrum. This wasn't about a mix-up over a single mistaken call or text; it was an endless barrage of messages about a past due bill—whether for mobile or internet, I couldn't be sure. What I was sure about was the inability to stop these notifications, despite my attempts. Texting "STOP" only led to more messages, ensnaring me in a cycle that felt impossible to escape.

To add to the frustration, as soon as I sent the "STOP" message, the system would immediately call me and leave a voice message, further entangling me in this relentless communication loop.

Even after calling and explaining to the operator that I had recently acquired this number and was receiving someone else's messages, the issue persisted. Two months later, I'm still caught in the barrage of those relentless notifications.

This experience, frustrating on a personal level, shines a light on a broader issue that extends far beyond my individual annoyance. It's indicative of a systemic problem in how companies manage data, particularly when it comes to reassigning resources like phone numbers. More importantly, it highlights a critical flaw in software development and customer service protocols: the lack of effective testing and the absence of safeguards to prevent such situations from occurring.

In the realm of software development, testing is not just a step in the process—it's the backbone of a reliable, user-friendly service. Effective testing should cover not just the functionalities of a system under ideal conditions, but also how it handles edge cases and unexpected scenarios. The case of receiving non-stop notifications meant for someone else is a perfect example of such an oversight.

Consider this: if software and systems were rigorously tested for how they handle changes in user data (like a phone number being reassigned), companies could anticipate and mitigate situations that lead to customer frustration. Testing shouldn't just ask if the system works, but how it fails and how it recovers when it does. This isn't just about reducing inconvenience; it's about building trust and ensuring security.

You might wonder about the real impact of misdirected notifications. While specific statistics are scarce, the prevalence of digital communications hints at a significant problem. For example, receiving 20-30 unwanted messages daily is not just annoying but signals a widespread issue potentially affecting millions. Considering Charter Communications serves over 30.6 million residential and SMB Internet customers and 7.2 million mobile lines (2023), the scale of misdirected communications could be vast.

The costs to the business from such issues are not insignificant. Call center operations face tangible expenses as representatives address complaints from these misdirected messages, diverting resources from other support areas and possibly affecting overall customer satisfaction. Network traffic costs also add up, with each unnecessary message or call consuming network resources, reducing efficiency, and potentially increasing operational costs.

Furthermore, the reputational damage and potential loss of customer trust from continuous misdirected communications can have profound financial implications. It could deter potential customers and affect subscriber growth rates and revenue. Given Charter's reported 2023 third-quarter revenue of $13.6 billion and net income of $1.3 billion, addressing these communication issues could not only save operational costs but also contribute to sustaining financial health through improved customer satisfaction.

If such a fundamental aspect as halting unwanted communications fails—evidenced by the inability to 'stop' the service, only to be further bombarded with calls—one has to wonder about the reliability and quality of their other service offerings. This situation raises questions about the overall efficacy and customer-centricity of their operations, underscoring the importance of getting the basics right for maintaining trust and ensuring a positive perception of all services provided.

Each misdirected message represents a failure in a system that's supposed to streamline communication, not complicate it.

This narrative isn't just a venting session; it's a call to action for better software development practices. Here are a few key takeaways for developers and companies:

Prioritize comprehensive testing
Beyond checking if a system works, test for how it behaves under stress, during data transitions, and in unexpected scenarios. It's crucial not to succumb to the pressures of moving quickly to the next task in an effort to accomplish more, often driven by leadership's push for agility and customer satisfaction. This push can sometimes result in a rush towards new initiatives without leaving appropriate room to ensure critical aspects are executed correctly. Instead, the focus should be on getting fewer things done, but ensuring they are done right. Quality over quantity is key, as it not only saves time and resources in the long run but also fosters trust and reliability in the services provided.

We've seen in the past how leadership can drive the agenda towards agility and immediate customer satisfaction, directing efforts towards the next 'big thing' without adequately ensuring that important tasks are completed properly. This approach can undermine the very goals it aims to achieve, highlighting the importance of a balanced, thorough, and quality-focused development process.

Real-world examples starkly illustrate the consequences of neglecting these principles.

The Boeing 737 MAX Tragedies

Highlight the dire consequences of insufficient testing and oversight. The rush to compete and the insufficient evaluation of the Maneuvering Characteristics Augmentation System (MCAS) led to two fatal crashes, underscoring the catastrophic outcomes of prioritizing market competition over thorough safety checks and balances.

The Healthcare.gov Launch Failure

Demonstrates the repercussions of deploying a system without comprehensive stress testing. The platform's inability to handle real-world user volume at launch resulted in widespread criticism and highlighted the importance of thorough testing in projects with significant public impact.

Knight Capital Group's Trading Disaster

The Knight Capital Group's trading disaster serves as a cautionary tale about the financial and operational risks of inadequate software testing. A defective algorithm led to a staggering loss of $440 million in just 45 minutes, emphasizing the importance of rigorous validation and testing processes in financial software to prevent such catastrophic errors.

These examples underscore the critical need for prioritizing comprehensive testing and quality over speed and volume. They remind us that the pursuit of agility and customer satisfaction must not come at the expense of thoroughness and reliability, highlighting the importance of a balanced and quality-focused development process in preventing failures that can have far-reaching consequences."

Implement user-friendly opt-out mechanisms
Ensure that users can easily stop receiving messages not meant for them. "STOP" should mean stop, without exceptions.

Regularly update and clean data
Regular maintenance of databases to remove outdated information can prevent many of these issues from arising.

Educate customers on data privacy and security
Helping customers understand how their data is used and what to do in cases of miscommunication can mitigate the impact of these issues.

As we navigate an increasingly digital world, the importance of robust, user-focused software development practices cannot be overstated. My experience with unstoppable notifications is a reminder of the work that still needs to be done. By emphasizing rigorous testing, clear communication, and respect for user data, we can transform frustrating experiences into opportunities for improvement. Let's not wait for the next wave of misdirected notifications to take action.

January 1, 1983: The Day the Internet Came Alive with TCP/IP

Alexey Shevelyov — Thu, 07 Dec 2023 05:44:07 +0000

In the 1970s, computing was an esoteric world. Mainframes, those hulking giants of processing power, hummed in the air-conditioned basements of academia, government, and corporate powerhouses. These machines were islands unto themselves, speaking languages of computation that were as varied as the organizations that housed them. They were standalone fortresses, with processing capabilities that, while impressive, were locked within their own walls.

However, a radical vision was taking shape, one that proposed connecting these computational behemoths across vast distances, allowing them to communicate and share resources. This vision required not just innovative thinking but also a technological leap that could bridge the gaps between these digital islands.

Enter two visionary computer scientists: Vinton Cerf and Robert Kahn. Tasked with the monumental challenge of creating a unifying protocol that could seamlessly link disparate networks, they began what would become one of the most significant technological endeavors of the 20th century.

Cerf and Kahn recognized that the diversity of computer systems, each with its own communication protocols, was a major barrier. They proposed a revolutionary idea: a universal communication protocol that could dissect and deliver messages across a network of networks, an internetwork, or what we would come to call the internet. This protocol would need to be robust and flexible, capable of finding the most efficient path through a maze of interconnected networks, and ensuring that data, broken into packets, would arrive intact and in order.

Their solution was TCP/IP, a duo of protocols that worked in concert. TCP is the protocol that takes on the task of ensuring data integrity. Like a meticulous librarian, it takes a large volume of data, indexes it, and breaks it down into manageable sections, or packets. It then ensures that each packet is sent, received, and reassembled in order, verifying that nothing is lost or garbled in transmission.

IP, on the other hand, is the protocol that concerns itself with the delivery of these packets. It's the postal service of the data world, stamping each packet with an address and sending it off into the network. It doesn’t guarantee the packets will take the same route, or that they will arrive in order, or even that they will arrive at all—that's TCP's job—but it does ensure that each packet finds the most efficient path to its destination at the time it enters the network.

This collaborative dance between TCP and IP, the breaking down and reassembling of data, the addressing and routing, was revolutionary. It transformed the way networks communicated and laid the groundwork for an open architecture networking environment.

The development of TCP/IP was a meticulous process. Cerf and Kahn, along with their team and contemporaries, engaged in extensive testing and refining. It was an environment of collaboration and innovation, with a shared goal that pushed the boundaries of what was technically feasible.

The adoption of TCP/IP by ARPANET on January 1, 1983, marked a significant milestone. It was the moment when the fragmented landscape of computing networks began to coalesce into a more unified entity. The protocols they had designed were robust enough to handle an increasing number of networks and flexible enough to accommodate future growth and technological advances.

The impact of Cerf and Kahn’s work is immeasurable. It underpins the very fabric of the internet, enabling everything from the global economy to social media, from educational resources to entertainment. It allows for an email to be sent across the world in seconds, for transactions to be processed instantly, and for information to be accessed from anywhere, at any time.

Their vision of a network of networks has become our reality. It has redefined communication, breaking down geographical and cultural barriers, and has fundamentally altered how we interact with the world and each other.

As we look back at the siloed world of computing in the 1970s, it is almost inconceivable to imagine it without the connectivity we take for granted today. The story of TCP/IP is not just a tale of technological triumph; it is a narrative of how two scientists’ vision reshaped the world, fostering an interconnected global society. This is the legacy of Vinton Cerf and Robert Kahn, and the enduring power of TCP/IP.

Achieving High-Level Atomic Operations in Go

Alexey Shevelyov — Thu, 12 Oct 2023 19:48:40 +0000

Achieving High-Level Atomic Operations in Go

Go offers first-class support for concurrency, but mastering the art of concurrent programming involves intricate challenges. One of the most critical tasks is managing shared state across multiple Goroutines, and that's where atomic operations come into play. The Go standard library provides a range of low-level atomic operations that can be leveraged to build thread-safe applications. However, these operations often require a deep understanding of memory models and can be cumbersome to implement. In this article, we explore how to perform high-level atomic operations using the go.uber.org/atomic package, making it easier to write safe and maintainable Go code.

The Scenario

Let's consider a real-world example involving a shared bank balance, a common scenario in financial software. Multiple threads or Goroutines may need to read or update this balance concurrently. While Go's standard library provides atomic operations to manage such shared state, it often lacks higher-level abstractions, which can make the code harder to read and maintain. That's where the go.uber.org/atomic package comes in handy.

package main

import (
    "fmt"
    "go.uber.org/atomic"
)

var balance atomic.Int64

func updateBalance(minAmount int64, change int64) bool {
    for {
        // Load current balance atomically
        currentBalance := balance.Load()

        // Check if balance is greater than minAmount
        if currentBalance < minAmount {
            return false
        }

        // Calculate new balance
        newBalance := currentBalance + change

        // Try to update balance atomically
        if balance.CompareAndSwap(currentBalance, newBalance) {
            return true
        }
    }
}

func main() {
    balance.Store(100)
    success := updateBalance(50, -20)
    fmt.Println("Operation Successful:", success)
    fmt.Println("Updated Balance:", balance.Load())
}

How It Works

Atomic Loading and Storing

The balance.Load() and balance.Store(100) methods are examples of atomic operations that safely load and store the value of the balance variable. These operations ensure that the value of balance can be read or written safely, without being interrupted or accessed simultaneously by another Goroutine, thanks to the atomic methods provided by the go.uber.org/atomic package.

Compare and Swap: The Cornerstone of Atomicity

The CompareAndSwap method is the workhorse of our atomic operations. This method takes two arguments: the expected current value and the new value to set. It atomically checks if the current value matches the expected value and, if so, sets it to the new value. This operation is atomic, meaning it's done in a single, uninterruptible step, ensuring that no other Goroutine can change the balance in the middle of the update.

This replaces the CAS method we used earlier. While CAS offered similar functionality, CompareAndSwap is more idiomatic and aligns better with Go's naming conventions, making the code easier to understand.

Why `go.uber.org/atomic`?

You might wonder why not stick with Go's built-in atomic package? The go.uber.org/atomic package offers a more ergonomic API and additional type-safety, making it easier to write correct concurrent code. It provides a cleaner, more intuitive interface for dealing with atomic operations, as you can see from our example.

Managing shared state in a concurrent application is a complex but crucial aspect of Go programming. While Go's standard library offers low-level atomic operations, the go.uber.org/atomic package provides a higher level of abstraction, making it easier to write, read, and maintain concurrent code. By understanding and leveraging these atomic operations, you can write more robust and efficient Go applications.

The Lifecycle of an HTTP Network Request

Alexey Shevelyov — Fri, 22 Sep 2023 15:48:18 +0000

Before diving into each step, let's set the scene. Imagine you're in your web browser, and you click on a link. What's happening behind the scenes to make that webpage appear? It's a lengthy process involving multiple layers of the Internet infrastructure and various software components. The sequence of events is intricate but extremely vital for the world of web communications. Now, let's walk through the life cycle of an HTTP/HTTPS request and the role a Go application plays in this.

Step 1: Client Prepares HTTP/HTTPS Request

The very beginning of the journey is when the client, usually a web browser, prepares an HTTP or HTTPS request. The client formulates this request based on what resource it needs to fetch, such as an HTML page, an image, or some other file. The request contains essential information such as the URL, request method like GET or POST, and any additional headers. For example, headers may include user-agent details and accepted content types. Sometimes the request also contains a body, which is especially common in POST requests where additional data is sent to the server. When you type a URL into your browser and hit Enter, or when an application makes an API call, this is the process getting kickstarted. If the request is HTTPS, additional steps to secure the request are also initialized here, but we'll get into that in the next step. It's crucial to ensure the correctness of the request, as malformed requests are generally rejected by servers. Once the request is prepared, the client sends it out to find its way through the network labyrinth to the destined server. Essentially, this step initiates the client-server communication that forms the basis of the web.

Step 2: SSL/TLS Handshake (if HTTPS) (Request)

When a secure connection is needed, an SSL/TLS handshake kicks off. This process exchanges cryptographic parameters between the client and the server to establish a secure session. Initially, the client sends a "ClientHello" message to the server, specifying the encryption algorithms it supports, a randomly generated value, and other settings. The server replies with a "ServerHello," which confirms the settings both will use. Following this, server and client certificates are exchanged, and the encrypted session is established. Both parties have now ensured that they're talking to the right machine on the other end. In essence, this step locks down the communication channel, ensuring that the data exchanged is only accessible to the client and the server. This process is fundamental for the secure transmission of sensitive information like passwords, credit card numbers, and personal details.

Step 3: Local DNS Resolver (Request)

The client's local DNS resolver plays a crucial role in converting domain names into IP addresses. Your computer maintains a local cache of domain-IP mappings it has recently encountered. If the domain you're requesting isn't in the cache, your query has to go further. The local DNS resolver is essentially a client-side library that manages DNS query resolution. It understands how to forward a DNS query to get the required information if it doesn't have it locally. This step is foundational to how the Internet works because IP addresses are the actual addresses used for routing on the Internet. DNS makes it human-readable and manageable. For programmers, this is abstracted away, but understanding it can help troubleshoot network issues effectively.

Step 4: Recursive DNS Servers (Request)

If the local DNS doesn't have the IP address you're looking for, the query is sent to a series of DNS servers. These are usually managed by your ISP or another third-party provider. The recursive DNS servers have their own caches, and if they can't satisfy the request, they'll talk to root DNS servers, followed by TLD (Top-Level Domain) servers and finally the authoritative DNS servers for the domain. This is a hierarchical structure and often takes several steps. Each query might also involve multiple DNS servers before finally getting the correct IP address. Once the IP address is found, it's returned to the client and stored in the local cache for future use. Recursive DNS servers are vital cogs in the DNS architecture, connecting local queries to the global DNS infrastructure.

Step 5: Internet Service Provider (ISP) (Request)

Your Internet Service Provider, or ISP, acts like the highway system for your data. After your computer knows the IP address it needs to reach, the ISP takes on the task of routing your request across the vast network of the internet. It does this through a series of interconnected high-speed data links and routing stations. The ISP has complex routing tables and algorithms to figure out the most efficient path for your request. At this stage, the ISP's primary role is to get your request to the destination IP address as fast and reliably as possible. If there are any issues or bottlenecks in the network, the ISP will dynamically change the route. It's a crucial link in the chain, making sure your data reaches its destination and gets back to you.

Step 6: Firewalls (Request)

Before reaching the target server, the request has to pass through various firewalls. These are security systems designed to monitor and control incoming and outgoing network traffic. Firewalls act based on predetermined security rules and can be both hardware or software-based. The primary purpose is to establish a barrier between your secure internal network and untrusted external networks such as the Internet. Firewalls evaluate the header information in each data packet, like source IP, destination IP, and port numbers, to decide whether the packet is safe or potentially harmful. If the packet fails any of the checks, it's blocked or flagged for further inspection. Ensuring security is of paramount importance today, given the range of potential cyber-attacks and vulnerabilities.

Step 7: Router & Network Nodes (Request)

Once past the ISP and firewalls, the request enters the domain of routers and network nodes. Your request might pass through dozens of these on its journey to the target server. Each router it hits looks at the destination IP address and forwards the request along the most efficient route. These routes can be dynamically altered based on network congestion, failure, or other criteria. Network nodes act like the intersections in a road network, directing traffic to ensure it gets to its destination. Each of these nodes is also equipped with its own local routing table to direct packets. So, in essence, routers and network nodes serve as the internet's traffic cops, making sure data flows smoothly across the network.

Step 8: Cache Servers (Request)

Cache servers come into play in some network architectures, particularly those designed to improve performance and reduce latency. The primary role of a cache server is to store copies of responses from the web server. When a client requests a resource that has been previously requested, the cache server can serve that resource directly instead of fetching it again from the web server. This helps to reduce the workload on the web server and speeds up the response time for the client. Think of a cache server as a short-term memory for the network. It retains recently or frequently accessed data to quickly fulfill subsequent requests for the same data. This stage is especially useful for static resources like images or CSS files that don't change often. However, it's crucial to manage cache correctly to avoid serving outdated or incorrect data.

Step 9: Server-side Load Balancer (Request)

When the request finally reaches the server's local network, it often encounters a server-side load balancer. This device or software is responsible for distributing incoming network traffic across multiple servers. The goal is to ensure that no single server is overwhelmed with too much work. Load balancers use various algorithms to determine how to distribute the load. These might include round-robin, least connections, or even custom rules. Load balancers also perform health checks on servers and will stop directing traffic to a server if it's down or not responding. This is a crucial component for high availability and reliability in any network that experiences variable traffic loads. By efficiently distributing the incoming requests, the load balancer ensures that all server resources are utilized optimally.

Step 10: Operating System Network Stack (Request)

Once the load balancer decides which server should handle the request, the data packets are forwarded to the operating system's network stack on that server. This is a set of software components that essentially act as the gateway between the hardware and the application layers on the server. The network stack is responsible for the end-to-end communication between the client and server. It takes care of tasks like packet segmentation, reordering, and error checking. Once the packets are received and validated, the network stack forwards them to the appropriate application for further processing. The stack works closely with the kernel, which is the core part of the operating system, to perform these tasks efficiently.

Step 11: Go Application (Request)

At this stage, your Go application is finally in the spotlight. The operating system’s network stack forwards the incoming request to the application. The Go app starts by parsing the HTTP headers, method, and any data sent by the client. This could be form data, JSON payloads, or even files. Next, it often uses middleware for tasks like logging, request validation, or authentication. The core business logic of the app then takes over. For example, it may consult a configuration file, perform some calculations, or initiate a database query. Your Go code does the heavy lifting here, executing the logic that makes your application unique. The purpose of this stage is to process the incoming request and prepare an appropriate HTTP response.
Ah, here comes the part where your Go application shines. Once the request makes it through the OS stack, it's handed off to the Go application. Your Go app parses the request headers, the body, and any parameters. Then, based on the defined routes and logic, the Go app knows what function to execute. It might be fetching data, performing some computations, or generating an HTML page—whatever it's designed to do.

Step 12: Database/File System (Request)

Many web applications interact with some form of storage, be it a database, a file system, or a cloud-based storage service. At this point in the process, your Go app may need to query a SQL database to fetch user data, read a configuration file from the file system, or access images stored in an Amazon S3 bucket. The app does this to gather all the necessary data it needs to compile a complete and accurate response to the client's request. This is often where bottlenecks occur, especially if database queries are not optimized. Thus, this is a critical stage for the performance and reliability of your application.

Step 13: Go Application (Response)

Once your Go application has all the data and has executed the necessary business logic, it's time to construct an HTTP response. The app will build an HTTP header, set cookies if needed, and populate the response body, often using templates for HTML content. Your Go code will define what the client receives, whether that's JSON data, HTML, or a plain text message. The response is then passed back to the operating system’s network stack, which will handle the task of sending it back through the network to the client. This is the final stage of your application's involvement in this journey; from here, the focus shifts back to networking components.

Step 14: Server-side Load Balancer (Response)

As the HTTP response is ready to be sent back, it first goes through the server-side load balancer once again. Just like with incoming requests, the load balancer examines the outgoing responses. This often involves routing the response back through the same path it came in to maintain session consistency, a concept known as 'session persistence.' The load balancer's role is just as crucial for outgoing data as it is for incoming data. It ensures that all responses are directed correctly and optimizes the network resources in the process.

Step 15: Cache Servers (Response)

Now that the response is on its way back, it hits the cache servers again. If the data in the response is cacheable, these servers store a copy. This is highly useful for subsequent requests for the same resource, saving the need to go through the entire process. Caching strategies can be complex, involving expiration times and validation mechanisms to make sure the cache doesn't serve stale or incorrect data. Businesses optimize these settings to balance between performance and data accuracy. If done right, cache servers can significantly speed up data delivery and reduce load on the application servers.

Step 16: Router & Network Nodes (Response)

The response continues its journey, hopping between network nodes and routers. Each hop is a physical or virtual device that routes the packets to the next point in the path. This is like the reverse of what happened when the request was coming in, but it's just as crucial to get it right. Routing algorithms ensure the most efficient path, and routers look at the destination IP to decide where to send the packets next. Failures or slowdowns can happen, but redundancy and routing algorithms are in place to minimize impact.

Step 17: Firewalls (Response)

Before the response reaches the client, it has to pass through various firewalls again. Just like on the way in, these firewalls scan the packets for malicious content or signs of an attack. This is a two-way street; security is as important for outgoing data as it is for incoming data. Firewalls will check against predefined rules and security policies. If everything looks good, the packets are allowed to proceed. Otherwise, they might be dropped or flagged for further inspection, depending on the firewall's settings.

Step 18: Internet Service Provider (ISP) (Response)

We're getting close! The Internet Service Provider takes the data packets of the HTTP response and routes them back through its network to the client's local network. The ISP has a big role here, not just as a facilitator but also as a potential bottleneck. Network congestion, maintenance, or routing issues at the ISP level can impact the speed at which the response is delivered. This is the last network-level hurdle the response has to clear before reaching the client.

Step 19: Client Receives HTTP/HTTPS Response

Finally, the client's web browser gets the HTTP or HTTPS response. The browser starts by reading the HTTP headers to understand the type of content and any other settings or cookies. Then, it renders the HTML, CSS, and runs JavaScript to display the web page or handle the received data. For HTTPS, a final decryption step is performed to convert the data back into a readable format. At this point, the whole journey concludes. The user can now see the web page, download a file, or interact with the received data in any other way the application intended.

The Translation Lookaside Buffer (TLB) - The Cache Behind the Scenes

Alexey Shevelyov — Sat, 16 Sep 2023 19:51:06 +0000

The Translation Lookaside Buffer, known as TLB, is a special kind of cache inside the CPU. Its main job is to speed up the process of translating virtual memory addresses to their corresponding physical addresses.

Why the fuss about TLB? Well, every time a program wants to access memory, it's usually dealing with virtual addresses. For the computer to find the actual data, it needs to know the real, physical address. This translation can be a bottleneck, and that's where the TLB steps in. It remembers recent translations, making repeated lookups super fast. However, if the TLB can't find a translation, we get a "miss", and the system has to do a more time-consuming lookup in the page table.

Now, how does this relate to Go? The memory access patterns in your Go applications can influence the efficiency of the TLB. When data is accessed in a contiguous block, like in an array, it's more TLB-friendly. On the flip side, hopping around memory, as you might with linked-list structures, can lead to more TLB misses.

Let's visualize with a simple Go example. Imagine two ways of accessing data: one with a straight array and another with a linked-list type structure.

// Accessing data in a contiguous block
data := []int{10, 20, 30}
for _, value := range data {
    // Process value
}

// Hopping around memory
type Node struct {
    Data int
    Next *Node
}

func processNode(n *Node) {
    for n != nil {
        // Process n.Data
        n = n.Next
    }
}

In essence, while Go abstracts away many hardware intricacies, having an understanding of things like the TLB can help you make more informed coding decisions. However, it's also essential to remember that real-world applications require a balance. Being TLB-aware is great, but it's one piece of the larger performance puzzle. As you develop in Go, keep the TLB in mind, but always consider the broader context of your application's needs.

Understanding CPU Cache and Prefetching in Go

Alexey Shevelyov — Sat, 16 Sep 2023 19:37:38 +0000

In the high-speed world of modern CPUs, the difference between a program that performs well and one that lags can often come down to how effectively it interacts with the CPU cache. Go, with its simplicity and power, offers developers a unique opportunity to harness this potential, especially when combined with hardware prefetching.

Why Cache Matters
Imagine a sprinter who's lightning fast but has to stop and tie their shoes every few laps. That's akin to a CPU that's constantly waiting on data from main memory. The CPU cache acts as a ready stash of pre-tied shoes, ensuring the sprinter (or CPU) keeps racing ahead without unnecessary stops.

Arrays in Go, due to their continuous memory layout, play a pivotal role in this caching dance. When you access an array element, it's not just that specific element that's whisked into the cache; a chunk of nearby elements comes along for the ride.

Enter the Prefetcher
The prefetcher is like that assistant on the sidelines who notices the sprinter's predictable pattern and gets those shoes ready even before they're needed. If you're looping through an array in Go, the prefetcher catches on quickly. It anticipates future data needs and ensures the cache is primed and ready.

The Concert Line-up (Array vs. Linked List)

Imagine a concert where attendees (data points) stand in a line (array). The security checks each attendee one by one. This is efficient since everyone is in order. Now, imagine a scenario where attendees are scattered throughout the venue in random seats (linked list), and the security has to dart from one place to another to check each person. That's far less efficient, isn't it?

type Attendee struct {
    Name string
    Next *Attendee
}

func checkInLine(attendees []string) string {
    for _, attendee := range attendees {
        // Check attendee
    }
    return "All checked!"
}

func checkInSeats(attendee *Attendee) string {
    for attendee != nil {
        // Check attendee
        attendee = attendee.Next
    }
    return "All checked!"
}

In this Go example, checking attendees in a line (array) would be quicker than hopping seat to seat (linked list), thanks to caching and prefetching.

The Painter's Palette (Spatial Locality in Structs)

Picture a painter who has colors and brushes on the same palette. When they pick a color, the desired brush is right there, ready to go. This is like accessing data that's close together in memory.

type PaintingTool struct {
    Color string
    Brush string
}

func paintArtwork(tools []PaintingTool) {
    for _, tool := range tools {
        // Use tool.Color and tool.Brush to paint
    }
}

In our Go example, having the color and brush close in memory (in the same struct) is like the painter having everything they need within arm's reach, leading to quicker artwork completion.

Drawing it All Together
The magic of Go isn't just in its syntax or standard library. It's also in understanding how the underlying hardware, like the CPU cache and prefetcher, interacts with your code. By aligning your Go data structures with the natural rhythms of modern hardware, you can craft applications that are not just functional but also blazingly fast.

However, while these optimizations can offer significant speedups, it's essential to remember they're just one tool in a vast toolbox. Don't let the allure of cache-friendly code solely drive your architecting decisions. Instead, see it as an opportunity to better understand the cost and trade-offs of certain patterns. As with all engineering decisions, apply these insights where they make sense and serve your application's broader goals. After all, the best optimizations are those that fit seamlessly within the context of your project, enhancing both its performance and maintainability.

When a Breakfast Burrito Exposes the Need for Rigorous Software Testing

Alexey Shevelyov — Sat, 02 Sep 2023 13:37:11 +0000

The Craving that Sparked a Journey

After a week of non-stop work and home-cooked meals, all I wanted was a simple pleasure: a McDonald’s breakfast burrito and a cup of coffee. A desire so straightforward should have required minimal effort to fulfill, but my 5:58 AM visit to McDonald’s website served up something unexpected — a lesson in the critical need for accurate software testing. McDonald’s, which boasts a staggering 57.3 million monthly desktop website visits according to SEMrush data, has a level of digital responsibility that cannot be overstated.

Navigating the Web Maze for a Fast Food Breakfast

In an effort to satisfy my hunger, I turned to a Google search and clicked on a McDonald’s location page. It read, “Sorry, we’re closed — we will be open at 5:00 AM.”

I checked my phone. It was 5:58 AM CST. Then, right at 6:00 AM, the message changed to “We are open.”

This wasn’t just a hiccup; it was symptomatic of something more complex. A simple timing error could extend into a range of issues that jeopardize user trust and overall experience.

Digging Deeper into the Backend Behavior

My curiosity was piqued, and I delved into Chrome’s Developer Tools.

Chrome Developer Tools — Debugging mcdonalds.com, understanding where label is coming from

It was clear that the HTML, complete with the misleading time information, was compiled on the server side. There was no client-side JavaScript to blame here.

Backend returns HTML Back that contains the label “Open / Close”

Since I had navigated from a Google search, metrics are undoubtedly gathered for analytics. This tracking data offers a plethora of localization options that could be far more accurate than whatever method was currently failing at McDonald’s.

The Price of Inaccuracy in a World Obsessed with Precision

My experience brings to mind the words of Glenford J. Myers, Corey Sandler, and Tom Badgett:

One of the primary causes of poor application testing is the fact that most programmers begin with a false definition of the term. They might say:

“Testing is the process of demonstrating that errors are not present.”

“The purpose of testing is to show that a program performs its intended functions correctly.”

“Testing is the process of establishing confidence that a program does what it is supposed to do”

Thus, a more appropriate definition is this:

“Testing is the process of executing a program with the intent of finding errors.

[The Art of Software Testing, 3rd ed., Wiley, 2011]

Now, imagine the magnitude of this issue when scaled to 58 million monthly users. What might appear to be a trivial timing error to a developer could translate into widespread confusion or even distrust among customers.

Concrete Steps to Enhance Accuracy and User Experience

Removing the Label if Reliability is in Question

The first and most straightforward solution is to simply remove the feature if it cannot be trusted for accuracy. A feature that cannot reliably serve its function has the potential to do more harm than good. Inaccuracy not only sows seeds of doubt but also tarnishes the brand image.

Tests That Seek and Destroy Errors

The fact that such an error went live suggests inadequate testing.

It’s not enough to check if the software does what it’s supposed to do; you must also ensure it doesn’t do what it’s not supposed to. Test cases should be designed to capture a wide variety of scenarios, including time zones, devices, and browsers, to rigorously vet the system for errors.

Using Client-side Solutions for Maximum Accuracy

JavaScript offers client-side features like Intl.DateTimeFormat that can fetch time zone data right from the user’s device. It’s a reliable, efficient method to eliminate the types of errors that complicated my search for a breakfast burrito.

As we come to the end of this tale, from a seemingly simple desire for a breakfast burrito to an intricate analysis of software testing, I’d like to express my gratitude for your time and engagement. It’s an honor to share this journey with you. Being in a circle focused on high-caliber coding techniques can significantly minimize bugs and inefficiencies. It can, in a lighthearted way, speed up our ‘TTB - Time to Breakfast.’ Small glitches can reveal big vulnerabilities, but collectively, we have the potential to fashion a world where both our breakfast burritos and user experiences are unmatched.

Wishing you all a splendid weekend!

References
Myers, G. J., Sandler, C., & Badgett, T. (2011). The Art of Software Testing (3rd ed.). Wiley.

Understanding the Versatility of Go's %v Format Specifier

Alexey Shevelyov — Sat, 02 Sep 2023 08:00:58 +0000

Why %v in Go is a handy alternative to type-specific format specifiers, especially when you need quick and readable output.

Welcome to a comprehensive guide on one of the most versatile tools in the Go language, the %v format specifier. Whether you are a junior developer just diving into Go or a seasoned programmer, understanding %v will make your life easier. Let’s delve into it.

Why Formatting Matters in Go

Before jumping into %v, let's talk about why formatting is important in Go. Readability and debugging are often directly influenced by how well your data is presented. With Go's robust fmt package, you have a ton of options for formatting, but knowing when to use %v can save you time and keep your code clean.

Understanding the Versatility of Go's %v Format Specifier

The %v format specifier in Go serves as a multi-tool in your programming toolbox. Highly versatile, it offers a default way to format numerous data types. What makes it so useful is its blend of simplicity and adaptability.

Here's a quick example that shows %v in action:

import "fmt"

func main() {
    fmt.Printf("%v\n", 42)  
    fmt.Printf("%v\n", "hello")  
    fmt.Printf("%v\n", true)  
}

Interchangeability of %v and %d for Integers

You might ask, "Why should I use %v for integers when %d is available?" Well, %v can be a real timesaver especially when you're debugging or doing quick prints for testing. Plus, you get the same output.

fmt.Printf("%v\n", 42)  // Output: 42
fmt.Printf("%d\n", 42)  // Output: 42

Strings Made Simple with %v

Dealing with strings is commonplace in programming. When you don’t need any string manipulation or fancy formatting, %v can be a quicker alternative to %s.

fmt.Printf("%v\n", "hello")  // Output: hello
fmt.Printf("%s\n", "hello")  // Output: hello

Booleans: %v or %t?

In Go, boolean values are straightforward. They're either true or false. So when it comes to printing them, %v can do the job as efficiently as %t.

fmt.Printf("%v\n", true)  // Output: true
fmt.Printf("%t\n", true)  // Output: true

A Caveat with Characters

When working with individual characters or runes, %v will not be your friend. It will print the ASCII integer value instead of the character, which can be misleading.

fmt.Printf("%v\n", 'A')  // Output: 65
fmt.Printf("%c\n", 'A')  // Output: A

Choosing Between %v and %t for Booleans

Complex numbers are where %v shows some limitations. Though it will display a complex number, it lacks the precision that %g offers. For scientific applications, you might want to stick with %g.

fmt.Printf("%v\n", 1+2i)  // Output: (1+2i)
fmt.Printf("%g\n", 1+2i)  // Output: (1+2i)

Understanding the %v format specifier in Go is like getting to know an all-rounder in a sports team. It may not be the best in every category, but its flexibility and ease of use make it indispensable in many situations.

I appreciate you taking the time to read through this article. If you have any comments or questions, don't hesitate to reach out. Wishing you happy coding!

Resources

How Windows Subsystem for Linux (WSL) Revolutionizes Software Development

Alexey Shevelyov — Thu, 31 Aug 2023 18:17:39 +0000

In a computing landscape dominated by the likes of Windows and Linux, never has there been a more opportune moment for these two titans to collaborate. Enter Windows Subsystem for Linux (WSL), a groundbreaking feature that allows Linux and Windows to coexist on a single system. Before the WSL era, alternatives like dual-boot systems or resource-intensive virtual machines were the norms, each with their drawbacks. WSL has significantly changed the game, offering a high level of interoperability without the hassle of traditional solutions.

The engineering behind WSL is nothing short of brilliant, one of the standout features being its Dynamic Resource Allocation. Unlike typical virtual machines that allocate a fixed set of resources to Linux, WSL 2 adjusts its usage dynamically based on real-time needs, ensuring that the system's performance remains optimal. This is a departure from the traditional approaches and a leap towards efficient resource management.

Navigating between Linux's Ext4 and Windows' NTFS file systems has always been a hassle, but WSL ameliorates this through a File System Bridge. The bridge allows for seamless interactions between the two file systems, making it easier than ever to manage and share files between Linux and Windows. This is a technological leap that not only improves workflow but also optimizes how resources are used on your system.

The true genius lies in WSL 2's Full System Call Compatibility achieved through a real Linux kernel.

Unlike WSL 1, which translated Linux system calls into Windows system calls, WSL 2 provides an actual Linux kernel. This approach offers near-perfect system call compatibility, thereby allowing applications to run almost identically to how they would on a native Linux environment.
This has broad implications for software development, as it eliminates the vast majority of compatibility issues that plagued developers in the past.

But it's not all seamless; there are nuances to consider. For instance, although the Linux subsystem has its IP addresses, you need to use the Windows IP Address to access services within the Linux subsystem from another device on the network. This is due to how the underlying networking is configured, emphasizing that WSL operates within the context of a Windows environment.

Security is another area where Microsoft didn't cut corners. While the Linux subsystem can execute Windows binaries, the opposite is not possible. This Asymmetrical Execution Barrier offers an extra layer of security, ensuring that potential threats on one side do not easily migrate to the other.

The impact of WSL goes beyond just technological advances; it revolutionizes Cross-Platform Development. With WSL, developers can run the same tools, packages, and even containers, whether they are working in a Windows or Linux environment. This has removed many of the inconsistencies and barriers that developers faced in the past, offering a more unified and efficient development workflow.

Finally, WSL is also a triumph of Community Collaboration. Microsoft has been receptive to developer feedback, continuously incorporating community-suggested features like GPU support for machine learning tasks in WSL 2 and improved file system capabilities. This ensures that WSL remains responsive to the actual needs of its user base, providing a tool that is both powerful and versatile.

In a nutshell, WSL is not just a tool but a paradigm shift in how we think about operating systems and development environments. With features like Dynamic Resource Allocation, Full System Call Compatibility, and the File System Bridge, it has erased many of the lines that used to separate Windows and Linux. It's a technological marvel that speaks volumes not just about where we are today but also about the future possibilities in a world that is increasingly becoming cross-platform.

Balancing Personal Growth and Work-Life Harmony in the Tech Industry

Alexey Shevelyov — Thu, 31 Aug 2023 07:26:44 +0000

Exploring the Power of Personal Projects and Lifelong Learning

In the ever-evolving landscape of the tech industry, the pursuit of knowledge and personal growth is not just a luxury but a necessity. The dynamic nature of technology requires professionals to continuously update their skills, explore new horizons, and embrace lifelong learning. However, the benefits of personal projects and ongoing education go beyond just career advancement; they also play a significant role in achieving a harmonious work-life balance.

Personal projects offer a unique avenue for individuals to explore their passions, experiment with new technologies, and expand their skill sets. These projects provide a creative outlet that is often different from the routine tasks of a regular job. Whether it's building a personal website, developing a mobile app, or contributing to open-source projects, personal projects allow tech professionals to break free from the constraints of their daily responsibilities and embark on self-driven endeavors.

One of the advantages of personal projects is the autonomy they offer. Unlike traditional work tasks, where the objectives and requirements are defined by the employer, personal projects allow individuals to set their own goals and define their own success criteria. This autonomy encourages creativity and innovation, and it can lead to a renewed sense of enthusiasm for the field.

Additionally, personal projects provide an opportunity to explore areas that might not be directly related to one's current role. For instance, a backend developer might delve into frontend technologies, or a data scientist might experiment with machine learning algorithms outside of their usual projects. This diversification of skills not only adds depth to one's expertise but also enhances adaptability in an ever-changing industry.

Lifelong learning is another cornerstone of personal and professional growth in the tech world. Given the rapid pace of technological advancements, keeping up with the latest trends and acquiring new skills is essential to remain relevant and competitive. Online courses, workshops, webinars, and conferences are all valuable resources that provide opportunities to learn from experts and gain insights into emerging technologies.

However, the pursuit of continuous learning can sometimes tip the balance toward overcommitment. The desire to stay informed about every new technology can become overwhelming and lead to information overload. This is where strategic learning comes into play. Choosing areas that align with one's career goals and focusing on depth rather than breadth can yield more meaningful outcomes. Instead of attempting to master every new language or framework, investing time in mastering a select few can lead to more significant professional growth.

The intersection of personal projects and lifelong learning offers a unique opportunity to achieve a balanced work-life dynamic. By setting aside time for personal projects that ignite creativity and passion, individuals can find joy in their work beyond the demands of their job roles. Simultaneously, allocating time for continuous learning ensures that one's skills remain up to date and relevant.

When considering personal projects and lifelong learning, it's important to strike a balance that respects personal time and well-being. It's easy to become engrossed in a project or a course and inadvertently let it consume all available time. Setting clear boundaries and establishing a schedule that allows for both work and personal growth is essential. Just as professionals allocate time for work tasks, they should also allocate time for personal projects and learning endeavors.

In conclusion, personal projects and lifelong learning are integral components of maintaining a healthy work-life balance in the tech industry. By engaging in creative pursuits, diversifying skill sets, and continually upgrading knowledge, individuals can find fulfillment and professional growth. Striking a harmonious balance between work responsibilities, personal projects, and learning opportunities is a deliberate effort that yields both short-term satisfaction and long-term career success.

The Invisible Pressures that Affect your Work-Life Balance

Alexey Shevelyov — Thu, 31 Aug 2023 07:07:11 +0000

In the fast-paced realm of the tech industry, work culture plays a profound role in shaping the experiences and well-being of employees. While policies and procedures provide a framework for operation, it's the unspoken expectations and cultural dynamics that often exert the most significant influence. These subtle pressures can impact work-life balance, personal growth, and job satisfaction in ways that are not always immediately apparent.

Tech companies often pride themselves on their innovation and agility, traits that can lead to a unique work culture characterized by rapid development cycles, constant communication, and high expectations. The pursuit of excellence can sometimes translate into an "always-on" mentality, where employees feel the need to be available and responsive around the clock. This culture of hyper-connectivity can blur the lines between work and personal life, making it challenging to truly disconnect.

In many tech workplaces, long hours and late-night emails are not just tolerated but sometimes expected. The pressure to demonstrate commitment and dedication can inadvertently lead to a neglect of personal well-being. This unspoken expectation can hinder one's ability to recharge and maintain a healthy work-life balance, eventually leading to burnout.

Additionally, the tech industry's competitive nature can foster an environment where success is often equated with constant productivity. The fear of falling behind or missing out on opportunities can drive employees to work longer hours and take on more responsibilities than they can manage. This race to keep up can overshadow the importance of self-care and personal time, ultimately impacting one's mental and physical health.

Another facet of work culture that affects work-life balance is the pressure to conform to certain norms. In a rapidly changing industry, there is a continuous influx of new tools, methodologies, and technologies. Employees might feel compelled to stay up to date and proficient in various areas, even if it means sacrificing their personal interests and leisure time. This pressure can stem from both internal motivations to excel and external perceptions of what it takes to succeed in the industry.

It's essential to recognize that the expectations set by work culture are not always aligned with individual values and priorities. What might be acceptable or even celebrated within the company might not resonate with employees who seek a more balanced and fulfilling lifestyle. Finding a harmonious balance between fulfilling work commitments and maintaining personal well-being requires careful consideration and assertiveness.

Addressing the impact of work culture on work-life balance involves multiple layers of action. First, employees must acknowledge their own boundaries and communicate them effectively. While challenging, setting limits and asserting the need for personal time is crucial to preventing burnout. Engaging in open conversations with supervisors and peers can help reshape perceptions around availability and commitment.

Second, employers play a pivotal role in shaping work culture. Organizations that prioritize employee well-being, encourage work-life balance, and foster a supportive environment create an atmosphere where individuals can thrive without compromising their personal lives. By acknowledging the importance of both productivity and self-care, companies can promote a healthier and more sustainable work culture.

In conclusion, the hidden pressures of work culture can significantly impact work-life balance. The tech industry's rapid pace and high expectations often lead to an "always-on" mentality that can contribute to burnout and stress. Recognizing the influence of unspoken expectations and making conscious efforts to set boundaries and advocate for personal well-being is essential. As employees and employers work together to create a healthier work culture, the potential for both professional growth and personal fulfillment becomes achievable.

DEV Community: Alexey Shevelyov

It Has Been a While. We Need to Talk. Real Talk.

The Unstoppable Wave of Misdirected Mobile Notifications and Why It Matters

January 1, 1983: The Day the Internet Came Alive with TCP/IP

Achieving High-Level Atomic Operations in Go

Achieving High-Level Atomic Operations in Go

The Scenario

How It Works

Atomic Loading and Storing

Compare and Swap: The Cornerstone of Atomicity

Why go.uber.org/atomic?

The Lifecycle of an HTTP Network Request

Step 1: Client Prepares HTTP/HTTPS Request

Step 2: SSL/TLS Handshake (if HTTPS) (Request)

Step 3: Local DNS Resolver (Request)

Step 4: Recursive DNS Servers (Request)

Step 5: Internet Service Provider (ISP) (Request)

Step 6: Firewalls (Request)

Step 7: Router & Network Nodes (Request)

Step 8: Cache Servers (Request)

Step 9: Server-side Load Balancer (Request)

Step 10: Operating System Network Stack (Request)

Step 11: Go Application (Request)

Step 12: Database/File System (Request)

Step 13: Go Application (Response)

Step 14: Server-side Load Balancer (Response)

Step 15: Cache Servers (Response)

Step 16: Router & Network Nodes (Response)

Step 17: Firewalls (Response)

Step 18: Internet Service Provider (ISP) (Response)

Step 19: Client Receives HTTP/HTTPS Response

The Translation Lookaside Buffer (TLB) - The Cache Behind the Scenes

Understanding CPU Cache and Prefetching in Go

When a Breakfast Burrito Exposes the Need for Rigorous Software Testing

The Craving that Sparked a Journey

Navigating the Web Maze for a Fast Food Breakfast

Digging Deeper into the Backend Behavior

The Price of Inaccuracy in a World Obsessed with Precision

Concrete Steps to Enhance Accuracy and User Experience

Removing the Label if Reliability is in Question

Tests That Seek and Destroy Errors

Using Client-side Solutions for Maximum Accuracy

Understanding the Versatility of Go's %v Format Specifier

Why Formatting Matters in Go

Understanding the Versatility of Go's %v Format Specifier

Interchangeability of %v and %d for Integers

Strings Made Simple with %v

Booleans: %v or %t?

A Caveat with Characters

Choosing Between %v and %t for Booleans

Resources

How Windows Subsystem for Linux (WSL) Revolutionizes Software Development

Balancing Personal Growth and Work-Life Harmony in the Tech Industry

Exploring the Power of Personal Projects and Lifelong Learning

The Invisible Pressures that Affect your Work-Life Balance

Why `go.uber.org/atomic`?

Step 3: Local DNS Resolver (Request)

Step 4: Recursive DNS Servers (Request)

Step 6: Firewalls (Request)

Step 7: Router & Network Nodes (Request)

Step 12: Database/File System (Request)