With this series of posts, we’d like to focus on the tech point of view and show you how to map the high-level concepts into working software architecture. We’ll try to do this by way of designing an online marketplace architecture from scratch.
Let’s start with some definitions
Our working definition - an online marketplace is a virtual place where sellers and buyers meet to exchange goods or services. The exchange usually takes the form of transactions managed by the marketplace operator.
The operator measures the overall success rate of the marketplace by the number of deals between buyers and sellers. This is because they typically get a commission out of every transaction. So, to generate revenue it is the operator’s role to build a friendly environment which encourages:
- Sellers to exhibit
- Buyers to… buy
(usually in this order).
There are many niches you can target with an online marketplace. On top of this, there are many types of marketplace. So far, the market has come up with B2B, B2C, service, or C2C type. Yet the core mechanics of any marketplace platform are pretty much the same. Paraphrasing Mirakl, a well-oiled marketplace should provide these features:
- a promise of ever-growing traffic - to attract new sellers,
- a product catalog which stands out - and generates the traffic,
- a buyer-seller-operator communication and sales tooling - to spark off the confidence in buying
- a legal framework and transparent payment system - to finally close the sale, guarantee the quality, make buyers come back and start the cycle again
As you can imagine, these essentials have a huge impact on the design of the software the platform works on. What’s more, they often change over time. As much as we’d like to, we cannot cover all the cases up front. This is why, before we dig into the bloody details of the platform architecture, let’s talk a little bit about the context and key assumptions.
In this story, we assume we’ll be designing an early stage marketplace. Moreover, it’ll be a company which starts in a competitive market. You can call it a startup.
These 2 assumptions imply that the venture business model won’t be battle-tested. And this, in turn, entails particular requirements for the software underneath. In other words, to get a good time-to-market the platform should, therefore, be:
- Open to quickly handle new, unexpected business scenarios
- Super easy to change on a daily basis
- Ready to onboard and offboard developers fast
But it should also give the ability to:
- Learn from data
- Reasonably scale when unexpected traffic hits the platform
- Connect different departments
Also, the very fact of the article title introduces a serious assumption; we want to build marketplace software from scratch but why and what does “from scratch” mean after all?
“From scratch” redefined
Usually, when I hear this term, something positive pops into my head. Why? Because I immediately imagine a greenfield project with the freedom to choose the software practices and toolkit. I assume that having this kind of freedom should let me build the right software the right way.