Vue commerce, popularly known as vue.ai is a range of products powered by Artificial Intelligence, developed at MadStreetDen. It was started in order to help the e-commerce domains with a simple recommendation engine built using machine learning and image processing.

But right now vue.ai grew to an extensive suite of products leveraging the power of artificial intelligence right form the e-commerce website, marketing campaigns and retail stores to warehouse management.

It was quite a journey for us in the company. Moreover, the tech side journey was the most exciting. Let me tell you how I was a part of it and helped our startup to build a platform that paved way for the enterprise level products.

When I joined MadStreetDen, we had a very few clients. They were served by an ad-hoc, tightly coupled monolithic code base. The first task I did after joining the company is abstracting the engineering parts of the code from the core A.I parts.

Vertical Slicing

A birthday cake with rainbow sponge and stars on top, with a slice cut out and sat at an angle on the plate

Instead of approaching the codebase horizontally, we took out each piece of the abstracted code and started iterating it rapidly. Still overall architecture being monolithic, the engineering team took their own abstracted slice and developed it.

My role: During the early days I specifically took care of the ingestion part of the architecture. Since our clients are primarily e-commerce players, we will be provided with a huge set of product catalogs. I wrote services to consume data from various sources. Then parse it into our standard format (similar to Google product format), clean the catalog and fix the categories of the products.

Highlights: Python, Redis, Multi Threading, SQS, FTP, HTTP endpoints.

Go microservices!

microservices

Once we abstracted the monolithic codebase we got more insigts to the specific parts of the whole architecture. What kind of physical resource would each service use, which part needs to scale horizontally and which services should be always available.

For example, the ingestion part that I wrote can fail (at least for considerable amount of time). It doesn't affect the recommendations we show in our customer's e-commerce website. But the API servers should be highly available, else it will directly impact our client's sales. Talking about physical resources, the API servers doesn't need much processing power but they need to scale horizontally, in contrast our A.I service needs more computing power.

This is one of the experience from which I learnt that starting with monolithic first, then slowly abstracting your way out to create microservices is a sane way to build an architecture or software platform.

MicroServices I built

I built some microservices that powers this A.I platform. And they run in production without creating much chaos.

Ingestion service

I abstracted the ingestion part of the monolithic architecture into a microservice. It can be plumbed to different sources of data like HTTP JSON streams, FTP, CSV files and SQS queues. It cleans the data, fixes the product categories and feeds it into next microservice in the pipeline.

Highlights: Python, Redis, Multi Threading, SQS, FTP, HTTP endpoints.

Message Routing service

This microservice will receive the clean ingested data and routes it to different services and databases based on predefined conditions. It can scale horizontally to handle tens of millions of messages per hour.

Highlights: Python, Redis, Multi Threading, Concurrency.

Database Wrapper

Postgres being the source of truth for the data in this platform. I wrote an HTTP wrapper around the database. Apart from doing complex SQL queries using DSL like HTTP requests, it helped isolating the database access from other microservices. Not to mention that the rapid iteration in DB schema did not affect other microservices as the APIs are versioned. Now it is being auto scaled in par with the throughput of queries it receives.

Highlights: Python, Django, ORM, PostgreSQL