u/nickx360

it was the coin change problem.

i had game pass ultimate. the price increase made no sense at all. I can afford it but now I am like wth. might as well just buy the games. I don’t play many on day releases anyway. so sad I actually enjoyed using this service. oh well.

Finished the show and liked it too. :)

Thank you. This really helps me a lot :). I was led to believe an OS upgrade is next to Impossible.

Yeah we do own Service A. But they org doesn't want to change Service A because they are too worried. Hopefully I can convince them otherwise. :)

I followed these guidelines and shared my findings. Thank you so much for this. :). I have learnt a lot. This is really rock solid advice.

Depends on the role. If it’s engineering and senior position. Be ready for some leetcode. I got coin change problem. So a couple of those should get you by. First two were technical.

Just ask a lot of questions and be open about your thought process. They are generally quite nice. After that management round is just being excited about the role. Honestly it was a very good experience and everyone wants you to win.

I dunno. 🤷‍♂️

Oh apologies. If it helps. Service A on event wants to notify Service C (client). Service C was getting way too many notifications from Service A so they decided to solve it by adding Service B. It acts like queue system. Where it essentially executes all the requests for a specific id till a certain throttle point is reached and then shuts them off. Service A just keeps on sending requests till it gets confirmation from Service B that event has gone downstream.

I actually did suggest the queue system. But I need to confirm if more than just service A uses this system. The developer who built this system has been off work for a while. I have asked questions around but sadly I am just pointed to random metrics here and there.

Hopefully with all the wonderful advice I been given I can sort of map out my next steps. I ran service B locally and did a test of 1000 concurrent requests and it turns out it drops 67% of the requests. Our peak load is around 10,000 requests. So yeah I don’t know how this thing is standing. 🤪

Agreed. That is the best approach.

I understand. Yes that makes sense to me. I am going to use these points to figure out how to ask these questions. Thanks a lot and I appreciate the effort you took.

Honestly it’s been a little hard to even approach this for me. All of this helps me communicate better. Appreciate every advice.

yes, service a sends a throttle limit, service b checks if the throttle limit hasn't been exceeded for a specific id, if not then it forwards it to service C. If they are exceeded, it drops some pending quests for that particular id. Honestly it is quite complicated system. I got into this like last week only lol.

I see. Yeah that makes sense to me.

Thats actually not a bad suggestion. So a Service B which internally handles the queue, and sticky session id to route to the correct instance. This way we don't need to worry about Redis.

Sure! Also, any questions you ask help me better understand the problem.

Service A and Service B Interaction

Service A sends the following data based on user actions (e.g., when a user adds a widget):
- id (a unique identifier) - timeout - throttleLimit (number of parallel requests allowed) - requestId - clientIp

How Service B Handles Requests

Service B maintains an internal queue for each id. Whenever Service A makes a request with a given id, Service B appends the corresponding requestId to the queue.

Every 10,000ms, a loop runs through all the ids in the queue. For each id: 1. If the number of active requests is below the throttleLimit, an API call is made to the downstream client. 2. Once the request is completed, the connection to the client is released.

Additionally, Service B maintains a separate array to track ids that have reached their throttleLimit. Periodically, this array is checked, and any ids exceeding the limit are released to make space for new incoming requests.

Let me know if that answers your questions.

The goal of Service B queue is to prevent overloading the client. Service A keeps retrying until the message reaches the client, but we want to limit how many requests can be sent in parallel.

I need to read up on lockless algorithms to see if they could be a viable solution.
We can use UDP, but I’m not sure how that would help with throttling or if I’m missing something.

Wow thank you so much. :)

I decided to turn down the offer. Although they were amazing.

I just finished it and I enjoyed it quite a lot. :)

Thank you so much for your reply. :)

Sounds like a shitty person. Don’t be friends with them. Source: am vegan and don’t care about what others do or don’t with their lives.

Hey hey ,

Congrats on choosing to upskill yourself. This is the very first step of a long journey and most developers choose to not to do this.

Before you start with React. I’d suggest understanding vanilla js. Concepts such as closures , higher order functions and conditional returns are the essential building blocks which you will end up using in react.

More over react is a library. And the current best practices is to use it with a framework such as Astro.js or next.js

For an excellent JavaScript launch pad i would recommend eloquent JavaScript. https://eloquentjavascript.net/

Once you do that you can start with the following course

https://www.udemy.com/course/react-the-complete-guide-incl-redux/

Best of luck :)

Very cool. Thanks bud.

Yeah I agree. Although one needs a gig for experience hence the resume roast so a bit of catch-22 here.

You could go more in detail with your experience. How exactly did you streamline and optimize ?

Moreover if you are interested in ui/ux it doesn’t show up from this resume. If you want to stand out as ui engineer. Your resume needs a bit more visual flair. Just a very basic example.

Stay dark