Failing Silently is also an Option.

You can do better than showing Error Messages. Learn when and how.

Thank you to our sponsors who keep this newsletter free:

Multiplayer auto-documents your system, from the high-level logical architecture down to the individual components, APIs, dependencies, and environments. Perfect for teams looking to streamline system design and documentation management without the manual overhead. 

Failing Silently is a design choice in which some errors do not surface to the user but are handled gracefully in the background.

The idea is to prioritize the core user experience over showing error messages for every failure.

This approach is useful when the error occurs in a non-critical part of the application.

Why Use Failing silently?

1. Improved User Experience: Users aren't bothered by technical issues that don't concern them.

2. Focus on What's Important: The main features continue to work smoothly.

3. Avoid Confusion: Error messages can scare or confuse users, making them think the whole app is broken.

An Everyday Example: Online Shopping Recommendations

Imagine you're shopping online for a new pair of shoes. Each product page usually has a section that says "You might also like" with additional product recommendations.

This feature enhances the shopping experience but isn't essential.

What Happens When Things Go Wrong?

Suppose the recommendations service is having problems—it might be slow or not working at all.

Sketched using Multiplayer

But, your primary goal is to ensure the user can still browse, view products, add to cart, and check out without interruption.

Here's how failing silently can help:

1. Show Popular Items Instead

   • What the User Sees: Instead of personalized recommendations, the site displays a list of popular shoes, mostly from a pre-computed cache.

   • Benefit: The recommendations section remains useful without revealing any issues.

2. Hide the Recommendations Section

   • What the User Sees: The recommendations section doesn't appear at all.

   • Benefit: The page looks clean, and the user focuses on the main product they're interested in.

In both cases, the user continues shopping without encountering any error messages. They can view products, add items to their cart, and check out without any hiccups.

Let’s explore the idea in details:

Sketched using Multiplayer

This is part of the failing silently strategy—no error is shown to the user, but the issue is noted internally for future investigation.

The idea is to address the problem without impacting the user's experience.

Fail Silently in Action: Guidelines

1. Identify Critical vs. Non-Critical Features
   Determine which features are essential to the core functionality and which are supplementary.

2. Create Fallback Mechanisms
   For non-critical features, implement fallback logic. This could mean showing default data, retrying behind the scenes, or hiding the feature temporarily.

3. Log Every Failure
   Log each failure, even if it’s hidden from the user. This allows the technical team to identify and fix issues promptly.

4. Alert Without User Disruption
   Use alerts for internal teams (e.g., monitoring tools) rather than displaying them to the user.

Here is my decision-making process when handling errors:

Sketched using Multiplayer

When Not to Fail Silently

It's important to note that failing silently isn't always the best approach.

For critical features—like payment processing or account login—errors should be communicated to the user so they can take action.

Key Takeaways

• Failing silently is useful for non-critical errors that don't affect the main functions.

• Strategic ignorance prioritizes user experience by not displaying unnecessary error messages.

• Always log errors and alert technical teams even if the user isn't notified.

• Use this approach wisely; critical errors should still be communicated to the user.

Sketched using Multiplayer

The next time you see a service failing, remember:

How you manage errors can be the difference between keeping a user engaged and losing them in frustration.

---

System Design Classroom is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

---

Articles I enjoyed this week

• How Google Search Works by

  Neo Kim

• Kafka Load Balancing at Agoda for Terabytes of Data by

  Saurabh Dashora

• Design Spotify - System Design Interview by

  Ashish Pratap Singh

• Redis can do more than you think by

  Martin Joo

• Different ways of working with SQL Databases in Go by

  Alex Pliutau

---

Thank you for reading System Design Classroom. If you like this post, share it with your friends!