March is a Mail ARCHiving system - hence the name.
It has undergone extensive redevelopment over time as we attempted to deal with a variety of performance issues and system limitations that have impacted the primary deployment.
March was developed to support Codehaus; with over 900 email lists and 500000 messages this represents a pretty good test bed for most mail system solutions.
The architecture elevator pitch
- You
- Apache HTTPD
- HAProxy
- Thin Cluster
- Ruby on Rails app
- Memcached
- Postgres 8.3+
Why Postgres 8.3+
Using a single database type lets us use database specific features such as
- TSearch (TSearch is used for full-text indexing - GIN indexing)
- stored procedures / functions
- triggers (as part of our indexing solution)
It also means we can reduce our technology stack - no longer relying on Ferret / Solr means our memory footprint is smaller than if we had to split our
Why HAProxy
HAProxy is totally awesome for queuing connections while waiting for our thin instances to complete serving page requests. If any single thin stalls; HAProxy just sends to the other servers.
Using Apache's load balancing (in Apache HTTPD 2.0 at least) did not let us do fair load-balancing; a single stalled thin instance could take down the whole app
Why memcached
Disk I/O is phenomenally expensive. Codehaus' main mail server runs hot 24x7; by caching page fragments in memcached we lower the disk load on the server and deliver correct pages to clients much faster than ever before.
memcached lets us do some really neat caching things to ensure we're always getting up-to-date data.
