Meta Interview Question | System Design: Online Auction & Bidding Service (Revisited, 5+ Approaches)

[@SDFC]

NOTES & CORRECTIONS: - excalidraw file: excalidraw.com/#json=F9pXk1R2fi6HS_Y64ku19,3098QR5ScfqWSCWCQa-STA - text file: pastebin.com/ZW3z13LW

[@pengchen4556]

what is the reason using dynamodb / cassandra instead of mySQL? and for what reason use postegres instead of mySQL?

[@fragrancias972]

Do you have any more information on how to improve 2PC using Raft?

[@nishchaypareek8955]

How to handle concurrent requests to place bid? I do not want to accept a bid if it is lower than the winning bid.

[@SDFC]

So, "real-time enforcement of database constraints" is roughly the exact definition of the linearizability consistency level. Although it's hard to design this in a manner that would allow sufficiently reducing the consistency guarantee of the data store to something with clear availability improvements, I think it's at least worth avoiding linearizability (which only the highly costly option of Spanner can actually guarantee in distributed set-ups) -- this is why I prefer the event sourcing approaches that were described in the video. However, I will say that your requested conditions are an alternative approach that'd at least be worth exploring and considering in an actual design doc and for the sake of being comprehensive, so I wish I had considered that variation while doing the recording for this video. Something that I think could still possibly provide the real-time enforcement of "winning bids only" would be taking the manually sharded postgreSQL/MySQL approach and running the individual nodes on a high isolation level, such as "serializable". I think this might be considered "causal consistency" or "sequential consistency" for the overall set of DB nodes, and I think it's quite uncommon to provide "real-time constraints" for those consistency levels and this seems higher complexity imo, but it should work and would be a very fascinating approach. Great question. Thanks!

[@nomnom8692]

Which of the approaches is the best one on your opinion? (Sorry if you said in video, I just couldn't find)

[@alekseyklintsevich43]

I don't believe that you need OLAP at all here

[@SDFC]

correct, it’s completely avoidable However, that kind of pattern seems fairly common in practice (particularly at banks) and it seems like a genuine approach that somebody might consider, which is why the approach was still included and explored in the video for the sake of being comprehensive.

[@RSM.AUCTIONS]

Hi there, Im trying to make an auction website/marketplace. Ive just completed UI and now i need it developed. Is there anyone here that can tackle this? Best, Foz

[@TrendyTrends-qk9zf]

Diagram is over engineer to me with too many queues to decouple each component. It would be more practical to use some real data (maybe ebay) to determine the scale and TPS for Auction system. In addition, it will be more clear to design the system with defining requirements before drawing the diagram. It is just very confusing to change existing system without clear new requirements.

[@SDFC]

Okay, I normally ignore a comment like this one, but I want to assume the comment was "well-meaning" and treat it as an opportunity for learning or addressing some confusion: 1) They're "streams", not "queues" (except for the that last approach that somebody had explicitly requested in the live chat) 2) It sounds like you might not understand the purpose of message brokers beyond the "decoupling" mantra usually spouted as a quick explanation... By offloading the retries for partial failures to the downstream side of a message broker, your own service can remain available even when a dependency in downstream data flow experiences an outage (which happens hundreds or even thousands of times per week within the services running amazon.com -- brokers are a key component to why these outages rarely have a direct impact on the user experience for buyers) -- This is why message brokers are absolutely crucial for providing high availability in the majority of places with a service-oriented architecture. 3) You could design this for a scale of 10 TPS in the way that I know Square/Block likes to do in their interviews, but I've honestly always wondered what the point is of drawing a single box and single cylinder? Are they just testing that the new grads have actually taken a course on "intro to databases"? 4) I really do wish that I was doing machine count estimates with back-of-envelope calculations though. However, those require substantially less creativity and seem to usually show up as skipped in my video retention graphs whenever I've done them -- additionally, it's only one or two companies that actually care for those in senior+ rounds and if you're really trying to crack those interviews, then you can most likely figure out that part pretty easily on your own (but again, I would like to start fitting those into the videos again at some point) 5) The requirements are CLEARLY visible on the screen for the entire first 15-30 minutes of the video on the text pad covering the right half of my screen. In my opinion, this shows that you're likely just not paying attention. (I can empathize with how the length of these videos means that you're likely going to miss some stuff even if you do watch the whole thing, but dude, it was literally _right there_ for a big chunk of the video. -- I personally try to seek to disprove my assumptions before any attempts to provide feedback.) To give you another benefit of a doubt, you might be taking issue with my preference for doing multiple approaches, which I'm aware is "unusual" -- but, if you just want to see a quick regurgitation of a template derived from one of Alex Xu's books or a quick trash take by a new grad followed by the senior interviewer very politely confirming your suspicion that it was a trash take, there's literally more than a dozen other channels out there that are already doing that, so for clarification, that's why I have this "unusual" personal preference with my videos of trying to make something more comprehensive and similar to a case study than a mock interview.