My thoughts on the business case by AI (ChatGPT)

So I've decided to take on the challenge to build an e-commerce platform as a solutions architect for a new startup. The client? AI (ChatGPT). I have a business case that was generated for me by AI, and from it, I'd like to go through the intricacies and nuances of building a fully scalable platform.

Before we get into the solutions, here are my thoughts on the problem AI provided. Here is the business case to refresh your memory.

1. The scope

The scope of this particular problem is quite wide and would need an entire tech department to build and maintain. Companies pay thousands of dollars to have such a system developed. This problem spans multiple areas like solution designing, UI/UX, Development (Both frontend and backend code), Deployment, Monitoring, and then the cycle starts over. Visually, this is what that cycle ideally looks like.

2. Business case validation

From a product perspective, a business case of this scope would require its product team to conduct a lot of market research to prove that this is a viable business and the demand is as described. Only then can it warrant a solution that scales to serve clients between 5,000 and 50,000 in a day. It would be a good idea to start small and scale as demand grows. That way, you get to validate and iterate your value proposition with real customers.

3. ChatGPT has somewhat simplified this case.

What's fascinating here is that the AI has already done a lot of the heavy lifting. In a real-world scenario, a solutions architect would be the one translating the CEO's high-level vision and the business team's needs into these specific, quantifiable requirements. This ChatGPT-generated case essentially hands us the technical blueprint, skipping a crucial and often challenging part of the process.

4. Tackling the Mountain: Where We'll Start.

As much as AI has done some work for us, we still have a mountain to tackle. We know that we need to have 2 client pages, one for admins and the other for clients. We need to design the workflows for browsing the product catalog, cart management, placing orders, making payments, and sending notifications, to mention a few areas. We also need to bring all these together, and make sure that there is seamless Interservice communication. We need to design the authentication mechanism, the data layer and so much more. We will get into all these in detail in the coming sections of the series.

5. Technical interview point of view

If you were asked to design a solution for this in an interview, how would you approach it?

The first thing that comes to mind is the 2 client pages. We can serve these from a Content Delivery Network (CDN) such such AWS CloudFront or GCP's Cloud CDN. This ensures that the pages can load quickly globally since we'll have static content cached.

For the dynamic content, the clients call the backend via a load balancer that distributes the traffic to different backend applications. We can have the backend apps autoscale based on some metric of choice such as CPU or memory utilization, or even based on request count.

The backend reads data from the database. Between the applications and the database, we have caching enabled for frequently accessed data e.g product data. We can use least recently used(LRU) cache invalidation strategies to ensure we always have the latest version of the product data displayed to the customers. The other option we have is using least frequently used cache invalidation. However, this can be computationally expensive since we would have to keep track of the counts for each item accessed in the cache.

Once an order has been placed, initiate payment processing to Stripe (or whatever payment platform you prefer). We then receive callbacks via webhooks from the payment provider and send notifications to the customer on successful order placement or when the order has been dispatched.

Here is a pictorial depiction of the above:

The database design.
to store data, we would need the following tables: customer, product, order, order_items, users. Here is what the data schemas would look like.