Connected Commerce 1.0 :: GraphDB for Ecommerce :: Draft 0.1

A few months back I participated in a discussion with one of my client to discuss building a complete e-commerce platform on GraphDB. It was a very insightful discussion, where we come to know the basic problems that you might face with GraphDB but most of the problems were not technical but related to the steep learning curve, not a good team fit, slower development etc. As it was a startup, they can’t take chance on elongated deadlines so they finally decided to go to MongoDB which is still better than SQL to manage the master catalog system. Really, is that how you are getting ready for the future?

GraphDB has got a lot of popularity and community is getting better day by day. We have a 300% increase in the number of developers who are working with GraphDB. I was also not well versed with GraphDB use cases for an e-com company so I thought to give it a try and started to explore the complete landscape. 

Look at the competition between all the graph DB providers : 

Why shall we switch to GraphDB today?

First of all, why do we even think of moving from traditional SQL : 

• SQL is restrictive: It requires a predefined structure which is sometimes not possible in this ever changing requirement that comes from the business every day. It may be good for making complex queries but requires a significant pre-preparation and clarity up front.
• SQL is not optimal for scaling: Enforcement of locking, references check, transactions outside a single server is very tricky. 
• Sharding sucks in SQL and it hits performance - you can have a debate on this.
• SQL misses out on many features which are very hard to achieve e.g real-time recommendations, conversational commerce, ever-changing catalog design to capture product data, personalization, master data management etc. 

Leave this comparison here - here I am not trying to compare SQL with GraphDB, you might be knowing it already. I know there are many counterpoints as well, which make sense to a lot of SQL audience but if you don't start thinking about switching now to GraphDB you might be loosing on the opportunities which it brings in future. 

Lets have the courage to take a step forward and build something to support the current and future demands - connected data, building context, complex queries with faster performance, complex relationships etc. There are always workarounds which can be done on an existing system but it doesn’t make it better but worse. 

Taking a step forward doesn’t mean that you leave your things, get lighter and step forward. It is like adding more weight to your back and then stepping forward - this journey is going to be more painful than you think but eventually, you will shed your old loads and gain pace. It makes you slower at the start, but eventually, you will win the race. It gives you wing, accept it gracefully.

It is natural to think about connections 

Choosing a GraphDB is a big shift so should be done carefully - step by step - module by module. Designing the DB in SQL way is in our gene. It will take time to get out of this habit, but you will start loving designing with GraphDB because it is the natural way to store information. Ask any business person (not technical) to design graphDB design and they will do it really quick on the whiteboard. 

Few points to remember : 

• Neither SQL nor NoSQL meets the demand of connected nodes.
• GraphDB supports ACID properties . Period !
• Libraries like Gremlin which works as a facade between different GraphDB - you can use it with Neo4J, CosmosDB etc without thinking about any code change.
• Knowledge graph is easier to understand and maintain.
• GraphDB gives you flexibility to try out new business features faster.
• Neo4J comes with a graph visualiser and query language (Cypher) which is damn easy to understand - See in the below image.

Few Details (If you need it) :

Neo4J is the leader among all. CosmosDB is picking up slowly because of their scaling and auto sharding support for graphs. For a large scale e-com company, I guess CosmosDB fits well as it can scale to theoretically infinite nodes and auto-sharding (horizontal scaling) are supported well. Though, I am still to run my tests to confirm this. Neo4J also support in-memory sharding which effectively means you can maintain a pre-heated instance for quick responses. 

Graph DB advantage over document (MongoDB), key value (Redis) and SQL:

• Unstructured, Dynamic Schema and data can be stored in its natural way.
• In place or tables, entities and attributes, graphDB has nodes, properties, and relationship (edges).
• Knowledge graph is easy to understand. Data Visualisation tools are available by various GraphDB providers. MongoDB has no visualisation tool as it stores everything as a single document.
• Gremlin, Cypher : Many Interactive Query Language has been developed to make it easier to adapt.
• ACID support with complete fine-grained atomicity of the transactions. DocumentDB requires eventually consistent than ACID compliance.
• DocumentDB doesn’t create a relationship between data models but graph system requires the complex relationship 

This is my first draft on GraphDB adoption for larger e-commerce companies. I am still working on it. If you wish to get more details on my findings - you can comment below or drop a message.