01
Making four markets behave like one system
DataTechnology
Built a multi-store Shopify data layer after discovering that the existing connector could only work with one store at a time.
Some of the underlying business data and implementation details are proprietary. This case study focuses on the architecture, problem-solving approach and technical decisions rather than confidential commercial information.
The problem
The existing vendor connector could only work with one Shopify store at a time. That created an awkward ceiling for a business operating across four markets.
The data existed. The API existed. The interface between the two was the problem.
The question
What if the four stores could be treated as one system?
What I built
A multi-store Shopify data layer covering 4 stores, 13 tools, 3,463 lines. The system includes:
- OAuth client credentials
- automatic token refresh
- Keychain-managed secrets
- concurrent fan-out
- per-store failure isolation
- read-only defaults
- explicit write access per store
The interesting part
The hardest part wasn't calling the API. It was designing the system so that one store failing didn't bring down the other three. And making sure that "read-only" actually meant read-only unless a workflow explicitly required otherwise.
The principle
Don't accept a tool's ceiling as a system's ceiling.
What changed
Instead of repeatedly working around a one-store-at-a-time connector, the underlying Shopify data could be accessed across four markets through one reusable layer. That made a different class of analysis and automation possible.
What I learned
A limitation in the interface isn't necessarily a limitation in the underlying system. Sometimes the right answer is to go one layer deeper.