How is it even possible to design a whole system like Uber, ticket master etc in 35 mins. It is very difficult to come up with something like that in less than 35 mins when you don't have the domain experience. Add to that the pressure or stress of the interview environment, my mind just goes blank. Was recently asked about implementing a queue in a distributed cache system as an add-on to the original question. I realized right after the interview that I totally bombed it. Although gave a linked list based solution, did not explain it enough to say that it works on a Fifo basis. I totally bombed the interview from other aspects as well like not using the right database etc. Maybe practicing a lot helps. Just venting out what's in my mind. Feel really bad for not answering a basic Fifo question. If you reach here, thanks for reading through. :)
It’s pretty easy.
Timebox like crazy, count every minute and remember existing patterns of whatsapp, reddit, youtube, uber, dropbox, booking, maps, metrics collection, recommendation engine, ad click, etc. It takes time and intentional effort to improve.
Don't be so hard on yourself, systems design is a deep and sometimes controversial topic. Distributed systems add all kinds of complexity and questions. There is nothing particulalry wrong with storing a linked list and and using it as a central FIFO queue to coordinate. It usually comes down to the confidence and details which accompanied your solution, or "landmines" (a scenario where they have explicitly rendered some fundamental aspect of that solution inappropriate). A "failed" question isn't the end of the world, you can just focus on the confidence that you approach SD questions with. For me, I usually start a problem "upside down". That is, I start by walking the interviewer through the aspects of the target system that the question ISNT ASKING, with a whole bunch of assumptions, and declare those assumptions and gauge their reaction. That the question isn't asking? Yes! This is my recipe for boiling down the question into the most important parts, and discover any implicit constraints. Your mileage may vary: 1. Ingress and Egress: How do end-user interactions or input data interact with our solution? (Ingress -- A CLI, a network API call (from a browser, mobile app,other TCP connection, UDP datagrams, etc) , a hardware interface [pins, cables, keyboard], called from another software system API/ABI, given a file, a dense device input stream like a camera/microphone). Egress: we output a file, return API response, store in a DB, hardware output over the wire 2. "AAA" Authentication, Authorization, Auditing. Auth: How do we know that the end-user is truly who you think it is? (a 'real' IoT device and not a malicious user imitating one, that the sender of a network request is guaranteed to be the intended service (HMAC, TLS, Client Certs, ...). AuthZ: a user can't edit a concert ticket for sale, they can purchase. A social app can't edit other users comments or impersonate them. User types. Audit: how can we durably store actions taken on the system (start with simple immutable logging). 3. Availability, Performance and Load Scaling: Performance is how well we can handle expanding the size of inputs, load is how long well we can handle use of the system by many resources at once. This is where we try to estimate QPS, RPS, or some other proxy of maximum load. We should also set some reasonable bounds (specific to problem) on individual input sizes, latency, storage, bandwidth, SLOs (like "four nines" availability target. You might just add a note here on disaster recovery/continuity of biz as its an element of availability, but don't spend any time, just say it's part of achieving the target SLO. 4. Implementation Efficiency and Timeline: If the emphasis is on delivering rapidly, we might focus on developer enablement, using CoTS or open source tools, and place the priority on a working prototype. If not, we can focus on a more comprehensive, performant and secure implementation that considers IP and components that are bespoke to the project or are not readily available. If you need to deliver in 1 month the system will look very different than if you have 6 months. 5. Algorithms and Managed Services: We divide up our responsibilities here: for our Tinder clone, we will implement our own matching algorithm, but using Memcached/Elasticache/Redis. We don't need to implement a DB, that's a commodity portion of this product, so we will use Cassandra/Maria/RDS/Postgres etc. 6. UX/UI: for projects where users interact with a client or frontend, maybe this is as simple as CLI options or API endpoint design, maybe it is as rich as a 60fps graphical experience or mobile app with animations, 2d/3d rendered objects, image optimization, vector graphics, icons... 7. Security Surface & Monitoring/Observability 8. Test Pyramid (Unit/Integration/E2E) & QA
Wow, that's a very detailed answer. Thanks for taking time to write it.
Not sure to what level of granularity is being asked for in 35 minutes, operating that it is high-level components and interactions and data flows. Suggest going to Bytebyte-go, and looking up how sample architectures have been represented. These tend to be enough to address the components/interactions/data flows…. Good luck!
Try to actually practice writing down your system design solutions on codemia.io
It's a standardized test. You gotta treat it like one and prepare accordingly.