Introduction
At Wayfair, architects play a huge role behind the scenes. One component of our job is to identify gaps in designs and solutions and then create solutions to cover these gaps. If we identify a repeatable gap, we utilize a repeatable design pattern. This allows us to create a solution that addresses all of the gaps.
This blog describes a problem I found with a commonly overlooked gap in integrating external dependencies into apps and then walks through the design pattern solution I created to cover the void. The post also delves into the tradeoffs of using the solution, a how-to guide for implementing the design pattern, and the lessons our Wayfair team learned from using it.
The Problem
As always, it is best to start with the outlining problem. Our team was recently testing a new external software dependency. The use of external dependencies is not anything new. In fact, teams often use them to serve as reusable building blocks when creating and testing new product solutions.
These reusable blocks help accelerate development, but some risks come with using them, specifically when it comes to the customer experience. For example, external software dependencies can cause app crashes or failures with services. At Wayfair, we experienced app crashes firsthand from integrating external dependencies.
In this instance, our team performed a unit test. What we found was an external dependency that was occasionally sparking unexpected and undeclared errors. To address the problem, we needed to create a repeatable strategy that would minimize the potential risk by catching and reporting unexpected faults.
The Solution
This is where the Seismograph Design Pattern came to the rescue. It enables software engineers to implement fault tolerance, catch errors caused by external dependencies, and report them to issue management services for notifications and analysis.
To learn more, continue reading the blog here: link.