Moving the API to Amazon EC2
While working on Postmark and dealing with everyday small improvements we noticed we needed to take greater steps to keep it up with the demand. The volume of emails delivered by Postmark is growing from week to week and we’re thankful for it. It keeps us in shape; we have to keep up with new technologies so we can provide best service for our customers. We recently introduced several changes under the hood of Postmark – this article is on changes affecting the Postmark API.
Most important things first, these changes won’t break any of your existing code. They have been made internally, with the intention to improve your overall experience of using Postmark. We were working on three primary goals:
- Stability
- Performance
- Scalability
Also, this article covers changes to the Postmark Web API. Back in December, Hristo’s article covered similar changes in our SMTP engine. We used a lot of the same methods for the API.
Cloning the Web API
So, the interesting news is that we’ve cloned our API. What that means is that by running multiple server instances for the API service, we now offer a massively redundant architecture. I’ll try to summarize the benefits it provides, putting it into perspective of Postmark’s usage:
- Failover: when several copies of the same service are running, if one of them fails another one will take over. That’s how our Web API runs and that boosts our confidence in Postmark’s availability. In the previous architecture there was already a failover solution. However, the concept is now extended to multiple data centers for even higher availability.
- Load balancing: several copies of the same service provide you with the option of distributing load between them. When a new request for the service is made, the working copy with the least active load will be selected to handle the request. This way, a multitude of users will get the best performance from Postmark without ever having to know which physical server handled their request.
- Scalability: when a single service can be divided between several working units, this gives better options with overall system upgrades. To achieve greater volumes of processed emails, we’ll just introduce more processing power. More and more users are using Postmark and the volume of the email being sent is constantly growing. To keep Postmark up to its task, scalable solution was designed.
Quick technical details
The Postmark API is now served on a combination of Amazon EC2 and our dedicated environment at Rackspace. The EC2 instances are pretty lightweight and spread across multiple zones. The hosted API is lightweight itself, as Postmark is layered and modular.
Dynect is used to provide simple DNS load balancing between these instances. You can consult Hristo’s article regarding Dynect’s usage with SMTP instances. This allowed us to slowly introduce the new weighted instances into production to avoid site wide issues. It actually helped in a few cases where we noticed some issues, allowing us to reduce the traffic to those instances.
We tested the new tools, and they are providing overall better performance. This will reflect on the throughput of the emails we send, making our joint mission successful.
We have a lot more planned when it comes to Postmark’s architecture. We have built it from the ground up to handle failures at each level (DB, API, SMTP) without experiencing downtime. This strategy will be extended even more to ensure the best speed and availability possible.
