How Serverless Architecture Cut the Readability Parser API Costs by Two Orders of Magnitude

Serverless is a hot topic in software architecture; the author recounts how they refactored the Readability Parser API using a serverless design, dramatically lowering costs while providing a reference for generic architectures despite being built on AWS.

When the author joined Postlight, the first task was to rewrite the Readability Parser API, which extracts structured content from any web article. Three reasons prompted the rewrite: the legacy API was fragile and stored massive results in a database, the original author had left leaving knowledge gaps, and the service cost about $10,000 per month.

The rewrite goals were to produce a library with identical functionality, make it easy for engineers to contribute, and cut monthly expenses.

JavaScript was chosen so the code could run in both server and browser environments, leveraging the team's web development expertise. The old code was in Python, which lacks browser execution advantages.

To achieve cost savings, the team moved to a serverless stack using AWS Lambda and API Gateway, deploying with the Serverless Framework. After launching Mercury Web Parser in October, monthly costs dropped to about $400, a two‑order‑of‑magnitude reduction, thanks also to caching that eliminated many database costs.

1. Using Serverless Architecture

Adopting a serverless environment can dramatically lower hosting costs; after migration, the team saw a two‑order‑of‑magnitude cost drop, with further savings still possible.

Lambda’s free tier includes 1 M free requests and 400,000 GB‑seconds per month; memory allocation determines how long functions can run within the free tier.

Optimizing Lambda costs focuses on memory size, which directly scales with price; reducing memory or execution time lowers expenses. The team found reducing memory to be the obvious choice because their functions already run quickly.

2. Reducing Memory Allocation

Lambda memory can be set from 128 MB to 1536 MB. By continuously lowering the memorySize setting and monitoring latency, the team cut costs; halving memory roughly halves the price. For example, 1 M calls at 2 s each cost $33.54 with 1 GB, $16.87 with 512 MB, and $8.54 with 256 MB. Their parser runs with a 256 MB configuration.

3. API Gateway Response Caching

Caching responses in API Gateway reduces Lambda invocations. With a 0.5 GB cache and 1‑hour TTL, the team pays about $14 per month for the gateway, and cache hits cover 52 % of requests, saving roughly $240.

Scalability Considerations

Beyond cost, serverless reduces maintenance, configuration, and complexity. The same setup can handle from 1 000 to 100 000 000 requests, and scaling does not necessarily increase costs because cached responses handle the majority of traffic.

Final Cost Breakdown

API Gateway

Service fee: $137

Cache: $14

Data transfer: $42 (at $0.09/GB)

Lambda

Request fee: $3

Compute cost: $174 (average 2.37 s per call, 256 MB memory)

Total monthly cost: $370

Looking Ahead to the Future of Serverless

The team has used Lambda for many tasks—from web parsing to Slack bots, bulk image conversion, and video transcoding. Their experience shows serverless solves many problems, and Mercury Web Parser validates the approach.

About the Parsing Service

Postlight’s Mercury Web Parser powers several products:

Mercury AMP Converter – a one‑line integration for AMP sites.

Mercury Reader – a Chrome extension used by over a million users to strip articles of ads and distractions.

Bloomberg Lens – a Chrome extension and iOS app delivering related news, company data, and personal information for any article.

Thousands of developers rely on Mercury to extract structured content from any web article, handling 39 million requests per month for $370, i.e., less than $10 per million requests, with easy horizontal scaling.