Componentizing Shopify’s Tax Engine

How Shopify built for the long term by moving our tax engine to a componentized architecture within Shopify’s codebase with zero downtime.

Shopify logo
Shopify
•
Chris Inch
•9 min read•intermediate•
--
•View Original
MonolithRails

Overview

This article discusses the componentization of Shopify's tax engine, detailing the challenges of a complex codebase and the strategies employed by the engineering team to create a more maintainable and efficient tax calculation system. The process involved understanding existing tax logic, defining clear interfaces, and executing a systematic release plan to ensure no disruption for merchants.

What You'll Learn

1

How to define a clear interface for tax calculations in a componentized architecture

2

Why understanding existing tax logic is crucial before componentization

3

How to systematically release a new component without impacting existing functionality

Prerequisites & Requirements

  • Understanding of tax domain complexities
  • Familiarity with component-based architecture(optional)

Key Questions Answered

What challenges did Shopify face with their existing tax engine?
Shopify's existing tax engine was complex due to the spread of tax logic across various components, leading to inconsistencies and difficulties in maintenance. The team recognized the need for a componentized architecture to streamline tax calculations and improve code manageability.
How did the team ensure the new tax component did not disrupt existing systems?
The team implemented an experimental code path that allowed both the old and new tax calculation methods to run concurrently. By comparing results from both systems, they ensured that the new component produced identical tax calculations before fully transitioning to it.
What strategies were used to educate the team on tax logic?
The team utilized an in-house tax Subject Matter Expert (SME) and engaged in weekly trivia questions about global tax practices to enhance their understanding of tax complexities. This approach helped them grasp the nuances necessary for effective componentization.
What was the process for updating the tax testing suites?
The team meticulously tested every line of code moved to the new tax component, re-checking existing unit tests and writing new integration tests. This comprehensive testing ensured that the new component functioned correctly and did not alter the overall system's tax calculation capabilities.

Key Actionable Insights

1
Establish a clear interface for components to ensure maintainability and ease of use.
Defining a clear interface allows developers to interact with the component without needing to understand its internal complexities, making future modifications easier.
2
Conduct thorough testing before and after componentization to avoid introducing bugs.
By validating both old and new systems during the transition, teams can ensure that the new architecture meets the same functional requirements as the previous setup.
3
Utilize subject matter experts to bridge knowledge gaps in complex domains like taxation.
Having an SME helps the team navigate the intricacies of tax laws and regulations, which is essential for creating accurate and compliant tax calculations.

Common Pitfalls

1
Failing to fully understand existing logic before attempting to refactor can lead to significant issues.
Without a comprehensive grasp of how tax calculations are currently handled, developers risk introducing errors during the transition to a componentized architecture.