Interview Experience 2: System Design(Messaging Queues)

Sharing our own experiences about interviews is fun(and a rather sad feeling because we remember the mistakes we did, at least that's the case with me).

But my last blog seemed to be performing well so sharing about one that happened before it, at a startup that intends to Redefine credit for
the Indian middle class. Not naming it but sure sharing the interview.

Cold emailed the CTO and got an interview opportunity.

I Cold mail people as a hobby and hardly get a reply even with the resume I’ve, I don’t understand the industry anymore

The first question asked was~ What are the perks of Golang?

Back then I was using Golang a lot but wasn’t in the details, so said it's easy to learn, comparatively fast, and easily scalable.

I think a lot of depth could be discussed here, like how goroutines are light threads(2–8Kb compared to 1–2 MB of Java), read here, and well explained.

We then discussed topics that I can’t recall better, but time to jump to the main topic, the system design question which was asked, and trying to recall as fast as I can.

Second question

Suppose we have some transaction IDs and we can check their status (whether transaction is verified or in-processing), and their processing from the third party can take from 0-24 hours to process. Meaning in 0-24 hours a transaction is verified by a third party. How would we solve this problem and let the user know  that the transaction is successful? Every transaction has a different time, meaning a new transaction can be verified before an old one.

Before I jumped on solving the problem, he told me in the real world we’ve webhooks that can help with this, so that when a transaction is successful webhook will let us know. But the problem here is we’ve to assume there are no webhooks, meaning whatever we do it’s on our part, we’ve to arrange our system in a way that whenever a transaction is verified the user receives the notification.

The funny part is, I didn't know what a webhook is, I mean what an idiot I was. To simplify what a webhook is, to my best understanding, it’s an endpoint that gives you data, meaning it’s not a pull mechanism, you don’t send a request to get data from it, it’s a push mechanism, it would push data to the seeking server.

How could I know a topic I was never given a task on, I mean the CS world is infinite, and everything is good to know, if I know many things depth is an issue, if I know depth then breadth is an issue like here.

First approach~ Use SQL

At this point in history, I was in no way near the idea of a messaging queue(actually I used a Kafka producer-consumer while working for Trell, but I don’t know how it completely slipped, I wasn’t the best at it since I wasn’t very clear with basics). So the best thing I could come up with is a SQL database.

Insert all transaction IDs as they come, put them in a table called unverified, and run a cron job ( a scheduled job), that would pick data from the table, check it and store the result. As expected we can’t have a single thread to run this, would probably have to use goroutines to check different entries, but the problem would be, what if two processes try to check the same status?

I had an idea that we can put another param check that suggested that about the status of the process, meaning whether data is already under processing or not. Well not that I know about partitioning I could have better told him that we can divide the database, and do a check accordingly.

This would be a problem if we have a million transactions to verify. We would definitely have indexed on our table, but since we’re picking them sequentially it is still gonna be a problem.

The interviewer was still not satisfied and told me I could mail him a solution by the next day. Well, I was clueless, what could I do? what the hell should I think?

One thing was clearly understood, this approach is definitely not the best out there, who would build such a system to solve such a problem?

Shouldn’t folks encrypt the password and then store it?

At the same duration, I was talking to Ayush Mahajan(under whom I interned at Trell), we were talking about something and spoke about queues and Kafka-related stuff.

Second approach~ Use Messaging Queues

I used Kafka in particular for this matter, could have been any other service like RabbitMQ(a tutorial about it here and here).

The transaction IDs are sent from the producers to the Kafka server. On the server, the data is broken into partitions to store a huge chunk of distributed data.
Now this server can send the data to the consumer groups, where the status of transactions is checked for success and failure, if the transaction is successful we can proceed to the next if not send it back to the queue.

We can use the same consumers as producers for this matter so that each consumer takes from each producer, and none is idle.

Since Kafka already implements load balancing we wouldn't have to put sweat there.

This was my second approach, now that I know about messaging queues better, I feel embarrassed reading the solution I sent him. But again it was pure research to reach a solution.

Seeing my old logic, codes and etc

I don’t know the correct approach yet but I feel queues would be a great way of solving this problem(waiting for someone to correct me on this).

I was of course rejected and I wasn’t even surprised because I chucked up pretty badly.