Building a Catalog — Part 1: The Core Object Model

Conceptualise and Design a Robust Catalog

Photo by Foo Visuals on Unsplash

To sell a Product or Service to a Consumer, or to manage raw materials for production in assembly line, or to manage the distribution of products from warehouse to hubs a central repository to store the product details is often required. This kind of central repository is generally termed as a Catalog.

In this article, I will walk you through the process of visualising how a Catalog might look and what are the steps and preparation required to build a fully functional and extensible Catalog.

What is a Catalog?

In general, a Catalog is a representation of a company’s product or service offerings. It includes detailed information about each item, such as product descriptions, images, prices, availability, and any other relevant specifications or attributes.

While most of the Catalogs are limited to store the basic product details, a few require a lot more than that. Along with the product details for the Consumer, a Company might also need information like where the product comes from, what is the raw material required for a product, how a product is built/manufactured/prepared, how the product is stored, how each product is categorised internally for Business and externally for End Users, details about its availability, tax slabs, etc.

Visualising the Catalog

Understanding the Big Picture

With the definition of Catalog, it feels like a straightforward requirement and something which is not too complicated to build. But let us dive a little deeper into what are the bare-minimum features that an average Catalog is supposed to serve.

1. Different types of Product: Different products might have their own unique set of attributes or details.
   — A Mobile phone needs to have information like display size, screen resolution, battery life, carrier information, etc.
   — A Shirt needs to have information like colour, size, fabric, washing instructions, etc.
   — A Table/Chair needs to have information like material, height, etc.
   → Hence different schema for different type of Products.
2. Access to different Products: Different users might have access to different products within the Catalog.
   — A buyer might see Shirts in the listing and nothing else.
   — A manufacturer see other products too like Buttons, Threads, etc., which are not visible to a regular buyer.
   → Hence Role Based Access to different products.
3. Access to different information about a Product: Different users might have access to different information about the same product.
   — A buyer sees basic information of the product like Name, Description, Images, or any other details as mentioned in above point.
   — A distributor needs to know information like storage temperature in warehouse, preferred mode of transit, etc.
   — A manufacturer need to know what are the different raw materials or products required to build the mentioned product.
   → Hence Role Based Access for different information about a Product.
4. Different Category Tree:
   — A Consumer uses the Product Categories to easily navigate to the desired Product. For example, a Consumer who needs a mobile charger can navigate like Electronics → Mobiles → Accessories.
   — A warehouse just needs very simple classification to maintain efficient storage. For example, simple categories like Electronics, Electrical, Apparels, etc are enough to store all the respective Products without further classification.
   → Hence different Category Tree for different users.

What kind of Information does a Catalog represent?

In general, a Catalog stores the following information about a Product or a Service.

1. Product Information:
   — Product Name/Title: The name or title of the product.
   — Description: A detailed written explanation of the product, including its features, benefits, and specifications.
   — Price: The cost of the product, often listed in the local currency.
   — SKU (Stock Keeping Unit): A unique identifier or code assigned to each product to track inventory.
   — Status: Indicates whether the product is Actively sold or not.
2. Product Attributes:
   — Size: Dimensions or measurements of the product, such as height, width, and depth.
   — Colour: Available colour options for the product.
   — Weight: The weight of the product in relevant units.
   — Material: The materials used in the product’s construction.
   — Brand: The manufacturer or brand name of the product.
   — Model: For products with different versions or models, the specific model being offered.
3. Images and Media: High-quality images or photographs of the product from various angles to visually represent it.
4. Product Variations:
   — Options related to the product that customers can choose from, such as size, colour, or capacity.
   — Different variants may have their own set of attributes and prices.
5. Category and Subcategory: The product’s category or classification within the Catalog to help customers navigate to relevant sections.
6. Pricing and Discounts:
   — Original product price and any discount or promotional pricing.
   — Information about sales, discounts, and special offers.
7. Shipping and Production: Details about production time of the product and shipping options.
8. Warranty and Returns: Information about product warranties, return policies, and procedures.
9. Keywords and Tags: Words or phrases associated with the product to improve search-ability within the Catalog.

How do these values get populated?

So far we have seen the dynamic nature of the Catalog. But before talking about how these values get populated let us look at the example below.

Example 1 — Shirts:

In above example, same shirt is available in different colours and different sizes. But each variant is not just changing by its colour and size but also the title, image and description is also changing for every variant.

Example 2 — Mobile Phones:

In above example, same mobile phone is available with different RAM and colour. And just like shirts, each variant has additional information that changes like images and details.

That means not the just the attributes are different for different products, but also which attributes can change and which attributes cannot change for a variant within a product can also be different.

Confusing enough? If just reading this requirement is so confusing then imagine the kind of error we can get while filling these details if they are not controlled and validated.

To enable safe and fast onboarding of the product, we use templates to define the blue-print of the Product. Template is nothing but a collection of attributes for a given type of product. It also specifies which attribute are global (non changing), which attributes belong to a variant (changing) and which attributes act as an anchor point (for example, a user can choose different phones based on a colour and then the description changes accordingly, but generally s/he cannot see different colours by selecting a description).

Using a template, attributes get clearly defined and avoids the unnecessary overlap of information. Which means using a template we can ensure that attribute like battery life never gets added to a product like Regular T shirt Small BLue. These templates are generally tied to the onboarding console and ensures that the input form only shows the relevant fields based on that template.

Designing the Catalog

Some commonly used resources in a Catalog

Just like any other application, Catalog also needs some building blocks or resources. While on a very high level we have discussed that the Product, Variant and their respective Categories are the key building blocks of the Catalog, here are few of the most commonly used resources that are used to store and represent these information respectively.

1. Attribute and Attribute Value:
   — An attribute in a Catalog is a distinctive quality or property associated with a product or service that goes beyond its basic description.
   — These attributes provide detailed information and may vary from one product to another.
   — Attribute Value holds the value corresponding to the attribute.
   — Example: size, colour, weight, etc.
2. Template:
   — A template is a collection of attributes that form the blueprint for specific products.
   — Templates are used to define the schema for different type of products and they provide us a safe solution to handle varying nature of the products in Catalog.
   — Product and Template may have their own template. This gives more flexibility in defining variations for a product.
   — For example, all the mobile phones will have one template with attributes like screen size and washing machines will have another template with attributes like rotation speed.
3. Product:
   — A product in a Catalog represents a specific item or offering that a business sells.
   — It is the core entity around which information is organised.
   — Example: Men’s Leather Jacket
4. Variant:
   — Variants, also known as product variations, are different versions or options of a particular product.
   — They are linked to the main product but have distinct attributes that differentiate them from each other.
   — Example: Men’s leather jacket brown small, Men’s leather jacket black large.
5. Bundle:
   — In simple words, Bundles are combination of 2 or more Variants of similar or different Products.
   — Bundles are designed to provide customers with added value, convenience, and potentially cost savings compared to purchasing each item individually.
   — Example: Burger Meals Combo (Burger + Soft Drink + Fries).
6. Category and Category Tree:
   — A category is a systematic way of organising and grouping similar products or items together based on common characteristics, features, or functions.
   — A category tree can be used to organise products into various product categories and subcategories, making it easier for customers to find and browse products.
7. Association:
   — Association typically refers to the practice of linking or connecting related products or items in a way that encourages customers to explore additional options or make complementary purchases.
   — Associations are established to enhance the shopping experience, promote cross-selling and upselling, and increase overall sales.
   — Example: A user might be prompted to buy a Popular Game on purchase of a Gaming Console.

Standardisation and Definitions

As one of the critical steps of designing a Catalog, it is very important that the use case for each organisation is clearly defined and the whole data setup is done in accordance with the defined requirement. Even though this Catalog design supports ample flexibility and extensibility, not having a clear understanding on different types of information that will be stored can lead to hacky and breaking solutions in the long run.

Few examples of standardisation could be,

1. Fixed pool of attributes to pick from while designing the template. For example, always use the thumbnail attribute to store the thumbnail or image of the product. This will ensure that front end or social media will not have to search through different attributes to find the right image.
2. Define the type of data that can be stored as part of the Catalog. For example, the thumbnail attribute can store only media information similarly product weight attribute can store only the weight of the product along with its unit of measurement and so on. This will prevent the misuse of the Attributes.

Security and RBAC

As we have observed that certain parts of the Catalog require data protection, control and audit it is a good choice to secure the APIs that require data manipulation or send sensitive data.

Here we have four different user interacting with different attributes of the same product.

1. Cataloger: They adds and updates the details of all the attributes for a Product and its Variants.
2. Consumer: A consumer can only see the primary details of a Product like Name, Description and Image.
3. Analyst: An analyst is interested only in the product name and which raw material is required to manufacture that product.
4. Marketing: Marketing team can create promotions for the products and update the respective deep-links for those products.

In real world scenario, different types of users interacting with the Catalog system can increase or decrease which may affect the final complexity of the role based access to the Catalog.

Summary

In this article, we have visualised how a Catalog can look like and how it can be used to serve different departments of an Organisation. Based on this information we have come up with a High Level Representation of Catalog Design.

In the next part of this article, I will dive deeper into building a detailed Database Model to store various information of the Catalog and explain how it can be leveraged to apply RBAC and other security features.

Feel free to share your thoughts, feedbacks or questions in the comment section below.