After spending many years working as a Ruby on Rails developer, I have had the chance to experience the benefits that come from one of the framework's main principles: Convention over configuration—If you follow conventions, you won't have to write a ton of configuration.
Active Record, the Rails ORM framework, illustrates this principle well. According to the standard convention, there's a predefined mapping between models and database tables. As an example, the User model maps to the users table and the user_id foreign key with zero configuration. The same mapping using Hybernate, the (in)famous JAVA ORM, would take dozens of lines of XML.
As a variation on the same concept, I would like to introduce a similar principle: Convention over synchronization—By following conventions, you won't have to write a lot of synchronization glue code, which adds unneeded complexity and cost to your business.
Especially in a world where microservices and APIs are replacing monoliths, too much synchronization between systems can be problematic. Therefore, you should try to avoid synchronizations altogether if possible.
One of the simplest conventions you can adopt when building an ecommerce site is to leverage SKU codes as shared identifiers to connect different data sources without having to write any glue code. In this article, I'll describe what an SKU is and how it can be used with some practical examples.
Connecting data sources using SKUs.
Stock Keeping Units (SKUs) are alphanumeric codes that are assigned to each product based on its characteristics. It is common for brands to assign unique SKUs to their product variants in order to identify and track inventory.
An SKU can be thought of as a unique identifier for a product within a company. This isn't like EAN or UPC barcodes, which are universal identifiers. As for the definition of SKU codes, there is no standard rule. It is basically up to each business to decide what coding convention to follow.
In a typical SKU code, there are multiple subcodes that are used to identify the specific characteristics of a product. As an example, the SKU for a fashion brand might consist of the concatenation of the department, model, material, color, and size codes in order to identify the product.
A consistent SKU scheme can facilitate the management of processes and integration between departments. In fact, what makes SKUs so powerful is that they act as the key for many types of data, making it easier for different services to interconnect.
In a perfect scenario, products, images, inventory, prices, etc. would all be provided by independent microservices. As you think of each microservice as a database table, SKU codes can be used to "join" data from different services and compose a product page.
SKUs are stored at the variant level in product catalogs. When you know a SKU in the context of a page, you can retrieve related information by assuming the format of each microservice. An image URL, for example, can be constructed based on the SKU code as follows:
It's the same for fetching a price or availability message for a product variant. If you have a SKU, your commerce API should be able to provide you with information about its price and availability. In a multicountry website, the customer would have already selected the shipping country, and you could use that information to localize the price currency or inventory location:
Another example is implementing an "add to cart" button based on the SKU code and, optionally, an item quantity:
I could give you dozens more examples, but I think you already get the point. There is only one convention that all other services follow. That way, composing a product page is far easier and requires no configuration or data synchronization.