How Serverless Architecture Streamlines Medical Image Analysis

Processing medical images like X-rays and MRIs is a cornerstone of modern healthcare, but as demand grows, so do the challenges. High volumes of data, complex computations, and time-sensitive workflows can overwhelm traditional infrastructure, leading to delays and inefficiencies.

In this blog, we walk you through our journey of revamping our medical image processing system. By transitioning from a resource-constrained legacy setup to a serverless architecture, we unlocked scalability, cost savings, and operational simplicity—all while improving patient care.

The Challenge: Bottlenecks in the Legacy System

Our initial approach relied on an ECS cluster service task with fixed CPU and RAM allocations. Images were analyzed sequentially and concurrently using threads. While functional, the system struggled to keep up with increasing demand.

🔹Key Issues

1. Processing Delays:
   Large backlogs of medical images caused significant delays, leading to slower diagnoses and treatment timelines.
2. Resource Strain:
   The fixed resources allocated to the ECS service task were often insufficient, resulting in frequent bottlenecks during peak times.
3. Scaling Complexity:
   Autoscaling was implemented to manage demand spikes but introduced additional overhead and complexity, slowing down the system even further.

It became clear that the legacy system could not handle the growing computational needs or provide the scalability required for future demands.

🔹The Solution: A Serverless Prescription for Scalability

To overcome these challenges, we re-architected our system using a serverless design powered by AWS services. This new architecture was designed for asynchronous, parallel processing with the following key components:

•  SQS (Simple Queue Service): Used to queue image processing tasks, enabling highly scalable asynchronous workflows.

•  API Gateway: Provided a secure interface for uploading images and retrieving their processing status.

•  EventBridge: Triggered workflows based on image upload events.

•  AWS Lambda: Handled lightweight pre-processing tasks, such as metadata extraction and validation.

•  Step Functions: Orchestrated workflows for managing complex image analysis pipelines.

•  ECS Fargate: Handled the actual image analysis in parallel by running containerized tasks with 1 vCPU and 2GB RAM per task.

•  DynamoDB: Stored metadata and status updates for processed images, enabling real-time tracking.

This serverless approach allowed us to process images in parallel, scale automatically based on demand, and eliminate resource bottlenecks.

Module 1: Data Ingestion and Queueing

In Module 1, the focus is on data ingestion and queueing to ensure efficient and reliable task scheduling. Two AWS services are used here:

1. Amazon API Gateway:

•  Acts as the entry point for the system.
•  Receives metadata such as imageId, URL, and other attributes related to the medical image.
•  By using this endpoint our other services can add data into SQS.

2. Amazon SQS (FIFO Queue):

•  Ensures that the metadata is queued in the exact order it was received.
•  Guarantees exact-once processing and message deduplication, which are critical for consistent task execution.
•  Decouples the ingestion layer from the processing layer, preventing bottlenecks during high traffic.

By using API Gateway and SQS, Module 1 simplifies data ingestion while preparing the system for scalable and reliable downstream processing.

Related read: Integration of Amazon SQS with AWS Lambda and Django

Module 2: Dynamic Image Processing Workflow

Module 2 handles the image processing pipeline. It is designed for asynchronous, parallel, and fault-tolerant execution using the following services:

🔹Key Components of Module 2

Amazon EventBridge:

•  Triggers Step function to execute every 5 minutes (we can change as per requirements) whenever new messages are pushed to the SQS queue by Module 1.

•  Routes these events to the next stage of the pipeline for processing.

AWS Step Functions:

•  Orchestrates the entire image processing workflow.
•  Manages task dependencies, retries, and error handling, ensuring robust execution.

AWS Lambda:

•  This lambda generates JSON payload which will be iterated by step function.

•  Works seamlessly with Step Functions to reduce latency and optimize resource utilization.

DynamoDB:

•  Acts as the system’s status tracker.

•  Stores metadata, processing status, and other details for each image. This allows users to query the real-time status of any task.

AWS Fargate:

•  It uses JSON payload data that is generated by the lambda function, it passes these URLs and other stuff as input to tasks.

•  Executes the compute-heavy image analysis tasks in parallel.

•  Each task is dynamically provisioned with 1 vCPU and 2GB RAM, ensuring optimal performance without overprovisioning.

•  Eliminates the need to manage servers, providing a fully containerized, scalable computing platform.

Related read: Amazon EventBridge Essentials: Transforming Daily Task Automation

🔹Results and Benefits: A Healthier Architecture

Migrating to a serverless architecture delivered transformative results:

1. Enhanced Scalability:

The new system effortlessly handled fluctuating workloads, adapting dynamically to spikes in image volumes without manual intervention.

2. Accelerated Processing:

Parallel processing with ECS Fargate reduced image analysis times significantly, ensuring faster results for patients and healthcare providers.

3. Cost Efficiency:

The pay-as-you-go model of serverless computing minimized costs by eliminating the need for over-provisioning resources.

4. Simplified Management:

By offloading infrastructure concerns to AWS, our team could focus on application logic rather than server management.

5. Improved Reliability:

With built-in redundancy and fault tolerance, the system achieved higher uptime and better overall reliability.

Advantages of the Serverless Approach

Serverless architecture is designed to excel in scenarios like ours, offering several key advantages:

1. Scalability and Elasticity:
   Automatically scales up or down based on demand, making it ideal for unpredictable workloads like image processing.
2. Cost-Effectiveness:
   Pay only for what you use—no need to maintain idle resources during periods of low activity.
3. Reduced Operational Overhead:
   No servers to manage, patch, or scale; AWS takes care of the heavy lifting.
4. Faster Development Cycles:
   Developers can focus on building features rather than managing infrastructure, enabling quicker iterations.
5. Improved Fault Tolerance:
   Serverless services like Lambda and SQS inherently provide redundancy and resilience against failures.

Disadvantages of the Serverless Approach

Despite its many benefits, serverless computing does come with trade-offs:

1. Vendor Lock-In:
   Heavy reliance on a specific cloud provider can limit flexibility and portability.
2. Cold Starts:
   Functions that haven’t been recently invoked may experience initial latency, impacting performance in low-traffic scenarios.
3. Debugging and Monitoring:
   Distributed systems can be more challenging to debug, requiring specialized tools like AWS CloudWatch and X-Ray.
4. Statelessness:
   Serverless functions are stateless, requiring careful management of persistent data or session information.
5. Limited Execution Time:
   AWS Lambda functions have a maximum execution duration (15 minutes), which may not be suitable for all workloads.