Unlock skill-first hiring with HackerEarth today
Learn moreLogging millions of requests every day and what it takes
HackerEarth’s web servers handle millions of requests every day. These request logs can be analyzed to mine some really useful insights as well as metrics critical to the business, for example, the number of views per day, the number of views per sub product, most popular user navigation flow, etc.
Initial Thoughts
HackerEarth uses Django as its primary web development framework and a host of other components which have been customized for performance and scalability. During normal operations, our servers handle 80–90 requests/sec on an average and this surges to 200–250 requests/sec when multiple contests overlap in a time delta. We needed a system which could easily scale to a peak traffic of 500 requests/sec. Also, this system should add minimum processing overhead to the webservers, and the data collected needs to be stored for crunching and offline processing.
Architecture
The diagram above shows a high level architecture of our request log collection system. The solid connection lines represent the data flow between different components and the dotted lines represent the communications. The whole architecture is message based and stateless, so individual components can easily be removed/replaced without any downtime.
You can read a more detailed explanation about each component in the order of data flow.
Web Servers
On the web servers, we employ a Django Middleware that asynchronously retrieves required data for a given request and then forwards it to the Transporter Cluster servers. This is done using a thread and the middleware adds an overhead of 2 milli seconds to the Django request/response cycle.
Transporter Cluster
The transporter cluster is an array of non-blocking Thrift servers for the sole purpose of receiving data from the web servers and routing them to any other component like MongoDB, RabbitMQ, Kafka, etc. Where a given message should be routed to is specified in the message itself from the webservers. There is only one-way communication from the webservers to the transporter servers, and this saves time spent in the acknowledgement of message reception by thrift servers. We may lose some request logs due to this, but we can afford to do so. The request logs are currently routed to the Kafka cluster. The communication between the webservers and the transporter servers takes 1–2 milli seconds on an average and can be horizontally scaled to handle an increase in load.
Following is a part of the thrift config file. The file defines a DataTransporter service supporting a method with a oneway modifier, which basically means that the RPC call will return immediately.
Kafka Cluster
Kafka is a high throughput distributed messaging system that supports the publish/subscribe messaging pattern. This messaging infrastructure enables us to build other pipelines that depend on this stream of request logs. Our Kafka cluster stores last 15 days’ worth of logs, so we can make any new consumer that we implement start processing data 15 days back in time.
Useful reference for setting up a kafka cluster.
Pipeline Manager Server
This server manages the consumption of request log messages from the Kafka topics, storing them in MongoDB and then later moving them to Amazon S3 and Amazon Redshift. MongoDB acts merely as a staging area for the data consumed from the Kafka topics and this data is transferred to S3 at hourly intervals. Every file that is saved in S3 is loaded into Amazon Redshift, which is a data warehouse solution that can scale to petabytes of data. We use Amazon Redshift for analyzing/metrics calculation from request log data. This server works in conjunction with a RabbitMQ cluster which it uses to communicate about task completion and initiation.
Here is the script that loads data from S3 into Redshift. This script handles insertion of duplicate data first by removing any duplicate rows and then by inserting the new data.
What’s next
Data is like gold for any web application. If done the right way, the insights that it can provide and the growth it can drive is amazing. There are dozens of features and insights that can be built with the requests logs, including recommendation engine, better content delivery, and improving the overall product. All of this is a step toward making HackerEarth better every day for our users.
If you have any queries or wish to talk more about this architecture or any of the technologies involved, you can mail me at praveen@hackerearth.com.
This post was originally written for the HackerEarth Engineering blog by Praveen Kumar.
Get advanced recruiting insights delivered every month
Related reads
Recruitment Workflow Process: A Complete Guide
Finding the perfect fit for your team can feel like searching for a unicorn. But fret not, fellow recruiters! Having a well-defined recruitment…
Conquer Your Hiring Challenges: Top Recruiting Software Picks for Small Businesses in 2024
In today’s competitive job market, attracting and keeping top talent is crucial for small businesses to thrive. But for busy small business owners…
How To Become A Technical Recruiter: Your Guide to Launching a Rewarding Career
The tech industry thrives on innovation, and at the heart of that innovation lies a crucial role: the technical recruiter. Why Technical Recruiting…
How To Use Live Coding Interviews in Tech Recruiting?
In the fast-paced world of tech recruiting, finding the perfect candidate can feel like searching for a needle in a haystack. Resumes can…
Building a Strong Talent Pipeline: Strategies for Effective Sourcing and Engagement
Struggling to find the perfect candidate when a position opens up? Build a strong talent pipeline to streamline your hiring process and have…
How to Build a High-Performance Team
A high-performance team thrives by fostering trust, encouraging open communication, and setting clear goals for all members to work towards. By focusing on…