iOS System Design of an E-Commerce App
(Etsy Example)

Etsy app has a standard iOS tab-based navigation design with tabs for Home, Favorites, Updates, You, and Cart screens.

Home Tab

Home Tab displays the user’s main feed of product recommendations based on the user’s interests, tags, likes, etc. It also has a promo/hero section for some unique offerings (and likely for other new features, based on A/B testing) and other types of content like recommended stores, recently viewed items, etc.

It also has a search bar at the top and upon selecting it, the user sees a list of searches and can tap on Browse by Category to see the list of categories of items on Etsy. Ultimately, the user can get to another products list screen that looks much the same as the initial list of items in the Home Tab.

This is one of the features that your interviewer most likely will want you to focus on and design in detail. We’ll go deeper into Home Tab implementation later in the article.

Favorites Tab

Favorites Tab consists of two tabs/pages that display the list of favorited items and list of favorited shops.

Note that after you tap the favor/heart/like button on an item or a store and switch to Favorites Tab, you don’t see either list update immediately; it will update only after you pull to refresh. This likely means that Etsy doesn’t use a local storage database such as Core Data or Realm or SQL and instead relies on ephemeral in-memory storage. Also, most likely there is no centralized source of truth that is shared across the app for individual views in the app to observe and refresh upon changes.

Updates Tab

This tab displays notifications about the user’s favorited items, orders, shops, etc. This tab was actually added as a new feature right after I started writing this article, so I will skip it.

But it is worth mentioning that this is an example of extendability and flexibility that your system design will need to support. It is likely that this new feature is rolled out to a certain percentage of all users, or an A/B testing group, rather than being shown to all users. In your design interview, you should address this and cover an A/B testing service of sorts that will be used throughout the app to determine what parts of the app are available for a particular user and change/adopt behavior accordingly. I’ll cover more about A/B testing services in a further section.

You Tab

You Tab displays a list of buttons to get to the user profile, messages, purchases & reviews, settings, and help screens.

Note that a lot of screens here either look similar or are exactly the same as the ones used in other parts of the app.

This is another important part of your system design — reusability.

Cart Tab

Cart Tab displays the user’s cart and “saved for later” items.

Product Details Screen

This is the main screen in an e-commerce app. It’s a complex view that displays product data such as title, description, images, shipping information, reviews, related items, etc.

It’s a very complex screen that usually is the one that makes money in an e-commerce app, so it’s crucial to architect it well and make it as extendable as possible. We’ll look into implementation details of this screen in further sections of this article.

Screens

Screens are the UI and View Controllers hierarchy necessary to build the app’s user experience. It is pretty straightforward.

Upon login, there is a container view controller displayed that holds the bottom navbar (either it’s a UITabBarController or, more likely, a custom view controller) and it has a view controller for the currently selected tab as its child view controller.

Home VC, Favorites VC, Updates VC, You VC, and Cart VC are container view controllers on their own, holding respective UI/VCs for features in those tabs.

When the user selects one of the tabs, the respective VCs are loaded. For example, for Home Tab there will be Search VC, Promo VC, Hero VC, Products List VC, and other VCs pushed onto the view tree hierarchy.

When the user selects an item in Products List VC, the app will push Product Details screen onto the navigation stack.

A similar process goes for other tabs.

We will get more into details of Home VC, Products List VC, and Product Details in later sections of this article.

Layers

By layers of our application, I mean the breakdown of all the objects we would need to play the roles and perform responsibilities every application needs. These layers are: UI layer, networking/service layer, storage layer, and business logic layer.

Dependencies

App dependencies that the business logic layer of an Etsy application will need are:

The above list is not comprehensive but captures most of the objects you need to architect Home Tab and Product Details screen. We’ll go over interactors and view controllers later in the article.

SessionStorage is responsible for storing the current user’s session; (i.e. if there is a session, the user is logged in; if there is no session, it’s a guest user).

UserStorage is responsible for storing local data about the user such as name, profile URL, etc.

ABTestingStorage is responsible for persisting A/B testing variations and feature flags.

LoginService is used upon login to make login requests with the user’s credentials and to parse login responses. It returns user data and current session upon success.

SignUpService is responsible for making new user signup requests and receiving and parsing/mapping new user signup responses. It will get back a user object and session object as the result of the signup request.

ProductsService is used to make product list requests (e.g. for Home screen) and to make product details requests for individual products.

CartService is used to make requests to retrieve cart data.

ABTestingService is used to get feature flags and A/B testing variables from the backend.

SearchService is used to get paginated lists of products for user search queries.

PromoService is used to get promotion banner content, image URL, and any other related data.

UserService is responsible for making requests to get data for the current user, such as username, profile picture, etc.

AnalyticsService is responsible for sending analytics data to the backend. Every time an interactor/presenter tracks a view, it will use this service to send Event objects to the backend.

CategoriesService is responsible for fetching lists of categories available in Etsy app.

CheckoutService is used to send requests to checkout and place orders.

UserMananger is responsible for managing the current user’s data. It uses SessionStorage, UserStorage, and UserService to fetch and store user data.

ABTestingManager uses ABTestingStorage and ABTestingService to get and persist feature flags and A/B testing values in the app.

Domain Models

Some of domain models that an Etsy app will need that will be coming from the backend are:

There are many more that I either omitted or that could be added, based on the specific implementation that you pick. But the domain models above are likely the bare minimum you’d have to be receiving from the backend.

Session represents a concrete session for a logged in, authenticated user using the app. Session object contains a token that is used to sign most of the requests in services to identify and authorize the user or to personalize response data.

User represents the current user with his or her username, name, profile URL, etc.

Product represents an individual product displayed in product lists. It has product name, image URL, product description, average review’s rating, etc. It also has Price, ShippingInfo, and Store in it as standalone models, as they are more complex data structures.

Price represents price calculation with or without applied discounts, promotions, etc.

ShippingInfo represents specific shipping data relative to the user’s address.

SearchResult represents a paginated list of products for a given search query.

Store represents all the data about a store — name, description, thumbnail image, banner image, etc.

Cart represents the current user’s cart with selected and/or saved products in it.

ABTest represents an individual A/B test and/or feature flag and a corresponding set of values (ABTestVariation).

ABTestVariation represents one specific value for a given ABTest.

Promo represents all the data (title, image URL, etc.) for a promotion banner in the Home Tab.

Event represents one individual event, such as a user tap on a button or a screen/page view. It has associated data, such as event ID, user ID, product ID, etc.

Category represents an individual category of items in the Etsy database. It may either contain subcategories or be a leaf category that has products.

These domain model objects are just structs or classes describing and holding data — they do not contain any logic.

Interactors, Presenters, Coordinator, Routers

Depending on the architecture you pick, the business logic (business logic layer) will go into either interactors, in the case of VIPER, or presenters in Model-View-Presenter or view models in Model-View-ViewModel (MVVM), etc. The main thing is that those objects will be using the dependencies from the list above to do useful work for the user, and then they’ll pass data to the view to render. They’ll also receive input from the view and coordinate navigation throughout the app.

Home Tab Features

To recap, when the user selects Home Tab, he or she sees a personalized list of items consisting of products, stores, categories, recently favorited items/stores, hero and promo banners, etc.

The user can navigate from there by selecting any of these items to view the products list, product details screen, category screen, store screen, and so on.

Home Tab Structure

This means that we can extend our app structure diagram to reflect that as follows:

The idea behind this structure is this — Home VC is a container that holds within itself SearchBar VC, Promo VC, Hero VC, Product List VC, and any other VCs for other types of content that needs to be displayed in that screen. VCs for each type of content are added as child view controllers to cells of Home VC collection view.

SearchBar VC displays the search bar; Promo VC, a promotion; Hero VC, any hero content, Product List VC displays product picks, etc.

Home Screen Dependencies & Architecture

Now, let’s wire up all the dependencies needed for the Home screen to work. There are two ways to go about it, and you should ask your interviewer about the system requirements and, based on that, decide which one to choose. The two choices are bundling and unbundling:

1. bundle all the data fetching and coordination in Home screen
2. split data fetching between children of Home screen

You’d pick the first approach if it is crucial for your app to load all the data first and display it all together.

And you’d go for the second approach if it is crucial for your app to display some content ASAP, and the rest of it can be loaded and rendered lazily as the app receives the data.

Neither approach is better or worse; it’s just a matter of product/UX choice and your Project Managers should know better than you and have more data and context to make this decision.

In our example, we will go with the second approach as it’s more complex.

Dependencies for each VC look like this:

As you can see, each VC has a corresponding interactor object. (In VIPER there is also a presenter between them, but I omitted it so as not to crowd this already crowded diagram).

Each interactor takes care of the business logic for its specific part of the screen, and it uses dependencies to do so.

Let’s take a look at each VIPER stack in detail:

Home VIPER Stack

HomeVC acts as a container and depends on HomeInteractor for business logic.

HomeInteractor depends on AnalyticsService and UserManager. It uses AnalyticsService to track when the tab was selected and when the user sees the Home screen again. It uses UserManager to get user ID and other necessary data for analytics and passes it down to children VIPER stacks as their dependency.

SearchBar VIPER Stack

SeachBarVC dispalys the search bar view. It depends on SearchBarInteractor for business logic.

SearchBarInteractor depends on SearchService, AnalyticsService, and UserManager. It uses AnalyticsService to track when the view was displayed and tapped on. UserManager and SearchService are passed to the next Search VIPER stack as the user starts the search.

Product List VIPER Stack

ProductListVC displays the list of product picks and depends on ProductListInteractor for business logic.

ProductListInteractor depends on ProductsService, AnalyticsService, and UserManager. It uses products service to fetch product picks, UserManager to get the current user’s details, such as user ID, to be used in products fetch requests for personalization, and AnalyticsService to track when this view was displayed, started to fetch data, finished fetching data, etc.

Hero & Promo VIPER Stacks

These two VIPER stacks are pretty similar and have a high chance of being exactly the same stack that is reused twice. In this case, for illustration purposes, I’ll assume they have two very distinct functionalities that justify the split.

Hero and Promo VCs are pretty similar. They display respective hero and promo banner views.

Both HeroInteractor and PromoInteractor depend on PromoService, AnalyticsService, and UserManager. PromoService is used to get the data for hero and promo content from the backend, and UserManager is used for personalization. AnalyticsService tracks which views are displayed and tapped on.

NOTE: Notice that we don’t have a standalone HeroService that fetches data for Hero VIPER stack but instead reuse PromoService. This is done for illustration purposes; likely in the actual Etsy app, those are two separate concerns, but, in our example, I decided to mix them together in one service to illustrate that they could be used by different interactors.

Data Flow in Home Screen

The data flow in the Home screen is delegated to each individual VIPER stack. When Home VIPER stack is initialized and displayed on the screen, it routes to and attaches SearchBar, Hero, ProductList, and Promo VIPER stacks. Those stacks will render their own UI, then their respective interactors will fetch the data they need and tell the UI to refresh itself. This way, we achieve decoupling of Home screen from concrete types it might contain and let them fetch their own data, which means we can add as many other VIPER stacks to that screen in whatever order we want.

For example, this is how data will flow in ProductList VIPER stack:

1. When Home VC attaches ProductList as its child view controller ,ProductList VIPER stack’s life cycle is triggered.
2. On ProductListVC’s viewDidLoad, it asks its interactor (through presenter as a proxy) to fetch the data to be displayed.
3. ProductListInteractor uses its dependency, ProductsService, to get the data from the backend.
4. ProductService puts together an HTTP request to fetch product picks.
5. ProductService receives back a response from the backend with JSON representation of product picks for the user.
6. ProductService maps the JSON it got to domain models and returns the result back to ProductListInteractor.
7. ProductListInteractor tells the view (through presenter as a proxy) to render the new list of product picks.

Data flows in a similar fashion in the other children VIPER stacks of Home Tab. Each is individually responsible for their respective scopes of the app.

Product Details Features

Product Details screen has many features such as:

• displaying product title
• displaying product description
• displaying carousel of product images
• displaying product store
• displaying product reviews count and average rating
• displaying product tags
• displaying product price
• displaying product shipping info
• displaying product variation picker and letting the user pick different variants
• displaying product quantity picker and letting the user change product quantity
• adding product to cart
• and many more

The user can also navigate to product reviews, other product lists, etc.

Product Details Structure

Overall structure of this screen will be similar to the Home screen where there will be a container view that holds a collection of children views that can be arranged in any order desired.

ProductDetails VIPER stack is a container stack that orchestrates what needs to be added to its list of children (ProductItem first, then PriceAndQuantity, etc.) and responds and coordinates all the routing from them (e.g. when the star button is tapped in ProductItem, it will route to Reviews VIPER stack).

Product Details Dependencies & Architecture

Just like with other parts of the app, each VIPER stack will have its own set of dependencies. Just like with Home Screen, we’ll go for a split data fetching approach where each component/VIPER stack fetches its own data, but you can go another route and have the container fetch everything in one bulk request and then tell children VIPER stacks to render data.

Dependencies for each VC look like this:

This is a very crowded diagram, but it encompasses the overall structure and architecture of this screen.

Let’s take a look at each VIPER stack in detail:

ProductDetails VIPER Stack

ProductDetailsVC acts as a container for any child VCs, such as ProductItem, PriceAndQuantity, etc., placed in it. It depends on ProductDetailsInteractor for business logic.

ProductDetailsInteractor depends on AnalyticsService and UserManager. It uses AnalyticsService to track when the screen was presented. It uses UserManager to get user ID and other necessary data for analytics and passes it down to children VIPER stacks as their dependency.

ProductItem VIPER Stack

ProductItemVC displays particular details about the selected product, such as store name, icon, location, number of reviews, product images carousel, product tags, product title/description, etc.

ProductItemIneractor holds business logic for fetching data and coordinating its display on screen. It depends on AnalyticsService to track data about user interactions, such as swiping to slide between carousel pictures and taps on review stars and store names. It uses ProductsService to fetch product data to be displayed.

PriceAndQuantity VIPER Stack

PriceAndQuantityVC displays price and/or discounts applied to the selected product. It shows shipping info and type/variation and quantity of item selected.

PriceAndQuantityInteractor coordinates fetching data to display price for selected price/quantity/discount combination. It uses PriceService to fetch the data and AnalyticsService to track user taps and quantity/variation selection.

Reviews VIPER Stack

ReviewsVC a list of recent reviews, total number of reviews, and overall rating of the selected item.

ReviewsInteractor coordinates fetching and displaying recent reviews for the selected item. It uses ReviewsService to fetch data and AnalyticsService to track when reviews were tapped on.

ProductList VIPER Stack

Here we want to display more items from the same seller, which is essentially the same product list as in Home Screen. We’ll be reusing ProductList VIPER stack and giving it a configuration to fetch only a subset of items from the store. All of its dependencies are the same (see it in the Home Tab section above).

We also will be reusing ProductList VIPER stack in similar fashion to display similar items list.

Data Flow in Product Details

Just like in Home screen, Product Details screen delegates data flow handling to its children VIPER stacks. When the Product Details screen is displayed, it attaches children VIPER stacks (ProductItem, PriceAndQuantity, Reviews, etc.) so that they handle each piece of this complex screen. These VIPER stacks then execute their own respective logic of fetching and displaying data and handle most of the user interaction.

Here is an example of data flow in Reviews VIPER stack that was attached to Product Details as a child:

1. When ProductDetailsVC attaches Reviews as its child view controller, Reviews VIPER stack’s life cycle begins.
2. ReviewsVC lets presenter know that a user interaction happened. In this case the “user interaction“ is just the fact that the view loaded on the screen (it was still because of the user action previously so it’s still considered a user action)
3. ReviewsPresenter asks ReviewsInteractor to fetch reviews to be displayed.
4. ReviewsInteractor uses its dependency, ReviewsService, to fetch recent reviews from the backend.
5. ReviewsService makes an HTTP GET request to fetch recent reviews data.
6. ReviewsService receives back a response from the backend with a JSON representation of recent reviews for the selected product.
7. ReviewsService maps the JSON it got to domain models and returns the result back to ReviewsInteractor.
8. ReviewsInteractor passes received domain models to presenter.
9. ReviewsPresenter maps received domain models to view models and tells the view to render them.

Data flows in a similar fashion in the other children VIPER stacks of Product Details screen. Each is individually responsible for their respective scope of this screen.