Subscribe to our
weekly update
Sign up to receive our latest news via a mobile-friendly weekly email
Drawing parallels with the Prime Video case study, we share our experience, the challenges we faced, and the lessons we learned with the implementation of our tracing collector API.
In the previous blog in this series, we delved into the redesigned architecture of Amazon Prime Video and how they integrated different architectural styles for optimal performance and cost efficiency. We also discussed the impact of Amazon’s decision on the concept of a “serverless-first” mindset, highlighting the importance of considering alternative architectural approaches based on specific use cases and requirements.
In this installment, we turn the spotlight on our journey with the implementation of our tracing collector API, drawing parallels with the Prime Video case study. We will share our experience, the challenges we faced, and the lessons we learned. Furthermore, we aim to address critical questions around the scalability of AWS Lambda, the applicability of serverless architectures in different scenarios, and the importance of monitoring in any architectural setup.
Our journey with implementing our tracing collector API bears a striking resemblance to Prime Video’s experience. The initial implementation, based on AWS Lambda and AWS API Gateway, allowed us to deploy the first version swiftly and gather user feedback promptly.
As we worked to productize this initial version, we ran into some challenges:
For these reasons (cold-start delay, API Gateway request cost, AWS Lambda idle CPU cost), we decided to migrate our collector API from a serverless to a non-serverless architecture. In this case, we redesigned our collector API by replacing AWS API Gateway with AWS ALB service and AWS Lambda with AWS ElasticBeanstalk service.
After performing this transformation, the rest of our platform (especially the parts with async processing, which weren’t directly user-facing) remained serverless for years and provided great scalability with no issues for cost.
Starting the collector architecture using serverless architecture allowed us to release our product earlier, an essential requirement. It allowed us to get crucial early feedback from customers. If we reencounter a similar scenario, we will probably follow the serverless-first mindset and consider starting with a serverless architecture again - and redesign it later if necessary.
Our journey with implementing our tracing collector API illuminated various challenges, including cold-start delays and increased costs associated with using AWS API Gateway and AWS Lambda. These challenges were compounded as our user base and, consequently, the volume of incoming requests to our collector API expanded. Despite the undoubted advantages of a serverless architecture, we recognized that, in our particular case, transitioning to a non-serverless architecture provided more efficient solutions to these challenges. This led us to ask an important question: Does AWS Lambda have scalability issues? Answering that question will form the basis for the next installment in this series.