Design Exercise: Purchasing System

For purposes of this exercise, you should attempt to make your design as over-the-top decentralized as you can imagine, The goal is to avoid any form of centralization whatsoever. 

Scenario

You will be designing a system to make online shopping easier. The buyer indicates to the system an intent to purchase an item. The system knows some of her preferences, vendor relationships, location, etc. It then matches the request for quote with any offerings from different sellers. If no offers match the system may submit the RFQ to sellers to have expressed interest in seeing RFQs matching specific criteria, along with relevant, anonymous information about the buyer. Each seller provides a personalized bid back to the system, either automatically from the offers they've expressed to the system or based on the information in their own databases and the data provided in the RFQ. The buyer's system processes those bids and notify the buyer about them according to her preferences.

Events

Your solution must use events. Define the types of events you'll need, along with the attributes that must be passed along with them.

Buyer data

What kind of data does the system need for the buyers? How is that data anonymized and passed to the sellers such that it can't be tracked back to the buyer?

Sellers

How does a seller gain access to this platform to submit bids? How does a buyer give preference to certain sellers who are allowed to make bids on her RFQs? How are new sellers discovered by the buyer? 

Decision engine

The big job in this scenario is matching buyer RFQs to seller offerings. This decentralized matching needs to take into account many different factors. How will the matching work? What information is in the RFQ and how is that matched to seller offerings? How do shoppers further filter the results? 

Every buyer has different seller preferences. For example, I may prefer to buy a product from Amazon over some other merchant because I like Amazon, even though it may cost a little more that way. The buyer must be able to indicate her preferences in some way. You may decide how that is implemented. Some possible schemes are weighting or prioritizing merchants.

Notifying the Buyer

A buyer can specify how she wants to be notified of new bids (e.g., email, SMS, the next time she visits a web page, carrier pigeon, snail mail, phone call, telegram, etc.).

It should be extensible so that third-party developers can create new ways of notifying the user. That is, you as the original system designer don't have to create the carrier pigeon module yourself.

A buyer may want to see only the winning bid or multiple bids.

Do This

For each of the following steps, use whatever documentation technique that you think will communicate your plans.

• Describe the roles of the event network actors. That is, what are the roles that users of the system will have? What functionality is available to each of the roles? Which are the primary use cases.
• Describe the event model. What events does each party raise? What are their attributes.
• Describe the persistent state for each of the primary actors in your system and how it’s affected by incoming events. 
• Describe the user interface for the primary use cases.
• What external APIs or services will you use?
• What internal API will you deliver?

Note: You don't have to do these in the order I have here. You may want to do them some other way.

Deliverables

Create a Powerpoint deck with exactly five slides:

1. Your title and name
2. Describe the primary roles.
3. Diagram the actors and the data each keeps
4. Show the main events and their attributes
5. Use a tool like swimlanes.io to draw the event flows for your system (concentrate on the primary event flows).  Event hierarchies are discussed in Chapter 12 of the Live Web. Here's a swimlane view of the event hierarchy in Figure 3 of Chapter 12. 

I'm expecting that you're spend 1:45-2:00 hours on this assignment. Don't overdo it.