Dynamic Image Resizer
RevX helps brands serve personalized ads to their users on programmatic channels across desktop, mobile web and mobile app inventory. To enable this personalization, we match user’s browsing behaviour with a catalog of products on commerce platform and showcase personalized product recommendations for each user in the ad.
Same Catalog Image Resized to Different Dimensions
RevX integrates with multiple ad exchanges and each of these ad exchanges has its own set of specifications for ad sizes. For example, mobile ads typically have size restrictions to avoid delays on slow data connections. To tackle this, we need to resize the original product image into a smaller footprint. Similarly, native formats have varying aspect ratios and sizes for the ad image.
RevX platform processes billions of ad requests per day from various supply exchanges for both web (desktop + mobile) and app. There is a strict SLA of <100ms for each ad request and hence resized images need to be available before we are ready to serve the ad.
Original product images in catalog feeds from advertisers can be quite large and need to be optimized for delivery on desktop and mobile devices. Considering the common ad banner sizes, we decided to maintain 2 additional size variations for every image – 460×460 for desktop and 100×100 for mobile devices.
We wrote a thin wrapper service on top of open source image transformation library ImageMagick which processed image re-size requests in batch. We also used Aerospike, a flash optimized in-memory NoSQL database for tracking whether a resized image was available while serving an ad impression or not.
The catalog feed processor sends request to image resizer service whenever a new product image is encountered through KAFKA bus. A key optimization was to resize images for only those products that were actively being viewed by users on the website/app.
This batch pipeline worked fine except for a small percentage of instances where the image was still in the resize pipeline and could not be served in the ad. For all such instances, we enabled logic to fallback to a third party cloud-based on-the-fly image resizing service to avoid missing ad opportunities.
However, as we doubled down our focus on mobile ads, specifically on native ad formats, this solution felt inadequate. There were many more sizes that needed to be resized as most native ad exchanges support multiple image sizes and aspect ratios.
Hence, to solve for new business use cases, we decided to replace our batch resizer with an on-demand image resizer that can resize images only when they were requested and serve it on the fly. The key requirement was for the resizer to be super-fast and it should be able to handle spikes in demand while being cost efficient.
We extended a base Apache HTTP module to implement our on-the-fly image resizing service. The module makes direct calls to ImageMagick C API based on the image transformation parameters in the request URL.
A typical resize URL looks like this: https://revx_image_resizer_host/resize/1200x627Padded,q_50/http://original_image_link.jpg
The request consists of a series of transformation commands separated by “/” followed by the original image URL. For instance, in the above example, the resizer is instructed to first resize the original image to size 1200×627 followed by padding and a reduction in quality to 50%. The list of supported transformations can be extended as per need including image and text overlays.
The service scales linearly with number of machines behind the load balancer (LB). In order to handle spikes in load, we auto scale the instances behind the LB based on current load. Additionally, the images are served to end users via a content delivery network so that they get served from the nearest edge server in the shortest time possible.
By making these changes, we reduced our image resizing costs by 4X while solving for even complex business use cases. It also simplified our ad server logic as we no longer need to keep track of which images are resized and which are not.
1. On the fly resizing has alleviated the pain of analyzing and configuring different image sizes coming in bid requests by accepting any size in the form of URL parameter, thus helping in achieving greater scale with lowered cost.
2. Both the approaches- batching and on the fly processing have their own pros and cons. Look at your business requirements and take a call accordingly.
3. Don’t compulsively build everything in-house. Look for available open source libraries and adopt them to solve your problem in an efficient manner.
If you have any doubts, queries or ideas, do reach out to us at email@example.com