is a comprehensive book on getting a job at a top tech company, while focuses on dev interviews and does this for PMs.
CareerCup's interview videos give you a real-life look at technical interviews. In these unscripted videos, watch how other candidates handle tough questions and how the interviewer thinks about their performance.
Most engineers make critical mistakes on their resumes -- we can fix your resume with our custom resume review service. And, we use fellow engineers as our resume reviewers, so you can be sure that we "get" what you're saying.
Our Mock Interviews will be conducted "in character" just like a real interview, and can focus on whatever topics you want. All our interviewers have worked for Microsoft, Google or Amazon, you know you'll get a true-to-life experience.
Requirements:
- Karan Shah November 02, 2014-> Unique Incrementing Id
-> Scalable
-> Available
-> Consistent
Solution:
First of all lets determine a solution that allows you to get the best unique id that starts incrementing from 0. We can use the time stamp and convert to epoch to get a unique id.
When we start this system we set a variable called START_EPOCH_TIME.
During each request we calculate CURRENT_EPOCH_TIME - START_EPOCH_TIME.
This should allow of us to get unique incrementing ids over the scale of the number of digits we use.
However, this won't work when there are multiple requests within the same time stamp. So first thing is we modify the length of our id by the number of requests we want per second. i.e. ID000 for 1000. So what we do is maintain a hash table that we recycle on regular intervals that maps epoch time and count of the number of requests. We update the table on every hit of the request.
REQ_COUNT [CURRENT_EPOCH_TIME] += 1
Our unique ID is then ID + str(REQ_COUNT [CURRENT_EPOCH_TIME]) .
If this is the only machine that handles requests then this shall work, however, this may not scale well when there are multiple machines handling requests. So lets say we have 10 machines handling requests. Then we use gossiping protocol to ensure that all the machines know about each other. This way we ensure that each machine knows exactly the number of machines that exist. Using this knowledge each machine assigns itself a range ordered by the machines IP/NAME. So for 10 machines. Machine 1 gets 0-100, 2 gets 100-200, 3 gets 200-300.
Then the hash table will be initialized with:
REQ_COUNT [CURRENT_EPOCH_TIME] = RANGE_START
And incremented as such.
REQ_COUNT [CURRENT_EPOCH_TIME] += 1.
Finally we always check whether REQ_COUNT [CURRENT_EPOCH_TIME] > RANGE. If so then we throttle the request. Otherwise if we want to handle more we need to update the way the system works. This should be decided based on the requirements and capacity of the system in handling these requests.