Functional

• User can bid certain items
• Auction can have fixed end time or variable one
• User look at item should get price update in real time
• Able to support hundreds of incoming bids per second from different users

Data

• Bid
  • bidId
  • auctionId
  • userId
  • price
  • server_timestamp
  • status
    • accept or reject
• Auction state
  • id
  • current bid id
  • price
  • end-time

how to order the bids

• Use Kafka message queue in the middle
  • High write throughput (log + kernel bypass ??? )
• Users notified of their own bid status async, can be delayed

bid engine design - need high throughput

• It only takes 32B to store the state of each auction
• hence we can keep this in memory
  • no disk read, not network call to a database
• As each request comes in, lock auction state, compare bids and proceed

Message delivery to interested parties

• backup bidding engine
• audit database
• other users

Kafka, where multiple consumer can subscribe to it

• Better fault tolerance, depending on replication configuration
• publish to Kafka before telling user if their bids was accepted
  • prevent risk of bid engine failing before data publish to Kafka
  • the more fault tolerant Kafka is -> more replication -> slower writes

def handleBid(auction_id, bid, price):
	auction_state = getAuctionState(auction_id)

	with lock:
		sequence_number = auction_state.next 
		accepted = bid.price > auction_state.price and time < auction.end_time
		if accepted:
			auction_state.price = bid.price 

	await uploadToKafka(bid, sequence_number, accepted)

	return accepted 

• Kafka can receive bids out of order