Large, complex and special marketing automation and email delivery systems are our favorite.
We certainly have gained the knowledge and the expertise over the years, and we have built our very specific, highly optimized, heavy-duty hardware for running large marketing automation instances.

IT Systems performance optimization is a passion of mine, from the bare-metal, to the file system, everything is optimized for large contact bases. Nothing else comes even close!

Hosting Large Marketing Automation Instances with clustered servers.

A large marketing database can be a huge burden with the tiered contact pricing of marketing automation platforms such as HubSpot, Salesforce, Oracle or Adobe. The annual pricing, for 300K or 1MM contacts, starts at no less than $125K per year.

It isn’t uncommon to see marketing departments renewing one to three-year contracts with marketing automation vendors for five, or even six figures annually.

Ours is a much more competitively priced solution, but what matters is that we can accommodate such large instances, while others might just ask exorbitant prices to compensate for their lack of optimization.

Not only the most cost-effective solution you can get if you have a large number of contacts. But probably also the best.

The investment to scale platforms which are meant for small and medium businesses to allow serving SaaS or Ecommerce companies with large customer and prospect bases is substantial, that is why we can offer better performance at better prices, because our software infrastructure was never built to serve thousands of small instances, but designed to serve large instances.
Large-scale email marketing has an up-front cost, but the operating cost thereafter is very affordable.
Some of the approaches that can be used to optimize Mautic for larger companies with sizeable marketing databases and email campaigns include:

External Load Balancing (HTTP/HTTPS) – A large Mautic deployment should not be hosted on a single server. It should be hosted on multiple servers running Apache or Nginx and PHP-FPM, behind a load balancer which can be managed by the cloud provider, or a custom load balancing solution such as HAProxy.

In a typical configuration, one of the Mautic backend servers is designated as the “lead instance” with cron jobs enabled. The “lead instance” batch processes segments and campaigns, while the other backends serve web requests that are generated by the Mautic tracking pixel and/or landing pages.

Shared Storage (for media) – A scalable Mautic deployment requires shared storage such as NFS (for a virtualized deployment) or a mounted volume from the host (for an LXC/LXD deployment).

Any Mautic instance has some data folders that need to be persisted, such as the media directory – containing images that are uploaded through the file manager in the visual builder. To preserve state, all the hardware nodes need to be able to access this data simultaneously.

Shared Storage (for PHP sessions) – A Redis key-value store should be set up to persist PHP sessions across multiple Mautic servers. This prevents users of the Mautic dashboard from encountering a “CSRF token error” when browsing through the different pages in the dashboard. Redis should be secured with authentication and/or an access control list because otherwise the session tokens can be compromised by attackers.

A poor man’s alternative to properly implementing session storage with Redis can include “session stickiness” at the load balancer level. This isn’t a perfect solution, as marketing users will time out when their cookie expires, potentially causing them to lose unsaved work. If you set the cookie duration too high, then the load will not be roughly equally balanced between all the available backends.

Multi-Master Database Servers – The Mautic application uses a replicating MySQL cluster to store the marketing databases. A multi-master database can improve the scaling of your database across multiple database nodes. Although each write needs to be mirrored over to the other master(s) increasing the latency on-write, multi-master significantly speeds up the read performance of Mautic with multiple database nodes. This leads to a more responsive dashboard, faster execution of campaigns, and speedier loading of embedded assets.

Internal Load Balancer (TCP) – An internal load balancer, separate from the aforementioned external load balancer, is required to balance the database queries across the multiple database nodes. MySQL clients (such as Mautic) use the TCP protocol to communicate with database servers over an internal network. Therefore, a load balancer such as HAProxy should be used to perform health checks on the database servers, and pass traffic accordingly. A limited privilege database user is set up for HAProxy so that it can tell whether a MySQL server is responding within the timeout threshold (i.e. healthy).

A considerable amount of effort is required to deploy a Large Marketing automation instance supporting large numbers of contacts, monthly emails, and web traffic. If your marketing department is struggling with either the high costs of other SaaS services, or the lack of responsiveness and performance, contact us, and we’ll provide your company with an adequate solution to your challenge.