Empathy and System Design

I am a software engineer with 6 years of experience in tech—really 12 years in a way if you count data science.

My previous work was in public health and reproductive justice. Work where the importance of empathy is quite obvious.

When I started software engineering, I knew there was a need for empathy on the backend with databases and the like, but I couldn’t quite explain it.

With frontend engineering, the case for empathy was a little more obvious. You have to make sure your user interface is accessible for those with disabilities and those who lack broadband internet by using separation of concerns principle with your HTML, CSS, and JavaScript files, you have to make sure your website can be readable on desktop and mobile devices, and you have to think of ways to keep your users engaged with your user interface.

Now that I am learning more about system design, which I associate with backend engineering, I am seeing more and more that empathy has its place on the backend as well.

I’m going to explain this in relation to one system design concept I learned about CAP Theorem.

What is system design?

The Roadmap.sh defines system design as “creating a detailed blueprint of a system's architecture, components, modules, interfaces, and data to fulfill specific requirements. It includes outlining a structured plan for building, implementing, and maintaining the system, ensuring it meets functional, technical, and business needs. This process addresses considerations of scalability, performance, security, and usability, aiming to develop an efficient and effective solution.”

CAP Theorem

Within system design, there’s a specific concept called CAP Theorem.

CAP stands for:

1. Consistency

2. Availability

3. Partition Tolerance

Consistency means that, regardless of the node a user is connected to, all users see the same data. For example, if a user buys a ticket on a ticketing site, all users should be able to see that the ticket was purchased even if they are connected to different servers on the backend.

Availability means that every request from a non-failing node must result in some response (even if it’s not consistent or the same for every user). Think about users going to Instagram. If the system has a high level of availability, the feeds will always be there even if the data is inconsistent across feeds.

Partition Tolerance means that the system continues to operate despite arbitrary partitioning due to network failure. Imagine you're using a ride-sharing app, and the connection between two servers goes down (e.g., the server tracking rides in one city can't reach the server tracking drivers in another city). The app might still allow users to request rides in one city (since the other server is unreachable) and continue processing local requests despite the partition. While the system may have incomplete data or be inconsistent (maybe it doesn't know about rides in the other city), it’s still available for users in the functioning partition.

CAP Theorem says that a distributed system (I’ll define that below) can have a high level of only 2 out of the 3 of these traits, but never all 3.

Why empathy is a superpower when making decisions about CAP Theorem

In the system design podcast I’ve been listening to, the host said that the dirty little secret about CAP thereom is that you always have to prioritize partition tolerance. That means when designing a distributed system, you’ll have to choose between Consistency and Availability.

The way to decide which to choose—consistency or availability—depends not only on the system but also on how the user would feel about having one but not the other.

For example, if we’re using a banking system, how would the user feel if their bank statement was unavailable for a few hours? They might be annoyed. But if their amount in their account was inconsistent with what they thought it should be, they would probably freak out. So in this case, consistency should win over availability.

Making these decisions when designing a system requires a level of empathy for the user.

Conclusion

Empathy in software engineering is not just about making beautiful and accessible frontend experiences. It also involves making decisions about the entire system. So if you are an empathetic software engineer, use your empathy as a superpower! Not something to hide.