Typical Placement in Infrastructure

Description

Depending on the tasks and operational requirements, Altcraft can be deployed in different ways. This page presents several simplified and most common deployment schemes in a customer’s infrastructure. These diagrams are intended for general reference and help to understand the basic principles of system design, on the basis of which a specific architecture is then formed according to project requirements. Key components in the diagrams:

• Control server — server(s) hosting Altcraft services and databases.
• Sending server — server(s) hosting the akmtad and node services, which are part of Altcraft.
• MTA (Mail/Message Transfer Agent) — the akmtad mail agent included in Altcraft, responsible for email delivery.
• Web resources — the customer’s or partners’ web resources where visitor tracking is performed.
• Users — system users: administrators, marketers, designers, etc.
• Applications — external or internal customer services that interact with Altcraft.
• Cloud messaging — cloud services for sending PUSH notifications (Google Firebase, Apple APNs, etc.).
• Subscribers — end users: buyers, subscribers, website visitors. In Altcraft they are tracked as profiles.
• Email services (ISP) — email providers (e.g., Gmail, Yandex, etc.) that receive email messages.

Regardless of the deployment method, the following questions must be addressed in advance:

• Which domain will be used for the control panel?
• Which domain will be used for tracking, pixel?
• Which domains will be used for From and MAIL FROM in email mailings?

Without Load Balancing

This scheme is suitable for the following cases:

• test or pilot deployment;
• deployment in external networks;
• implementation in small organizations;
• working with relatively small volumes of email mailings.

If necessary, access to the control panel and API can be restricted to the internal network. A distinctive feature of this scheme is SSL termination handled by Altcraft itself — the certificate is placed inside the service.

info

At the moment, Altcraft runs three separate Nginx instances, which requires three IP addresses on the server. Otherwise, launching on the same ports will cause conflicts.

The MTA interacts with ISPs directly, which allows the use of bypass mechanisms (various retry rules for automatic resending).

info

At least two IP addresses are required for sending. Depending on mailing volume and content type, more addresses may be needed to increase delivery speed and improve deliverability.

Using an SMTP Relay

This scheme is suitable for the following cases:

• test or pilot deployment;
• deployment in external networks;
• implementation in small organizations;
• working with relatively small volumes of email mailings;
• need to use an SMTP relay.

When using an SMTP relay, the Altcraft MTA must receive delivery reports (DSN, Delivery Status Notification). Such a report may be generated either by the relay itself or by the destination email service. The key requirement is that the domain in MAIL FROM (Return-Path header) must point to one of the IP addresses configured in the Altcraft sender (or the domain must resolve to the relay only for external servers — this can be achieved with Split DNS; in that case, the relay must forward received messages to the MTA). Upon receiving a report, Altcraft automatically processes it and records a delivery or non-delivery event.

With Load Balancing

This scheme is suitable for the following cases:

• implementation in large organizations;
• deployment in external or private networks;
• planned clustering;
• working with relatively large volumes of email mailings.

In this case, Altcraft can operate in a private network, while message delivery and HTTP interaction are handled by the customer’s infrastructure.

info

• All databases can be replicated, thereby improving the overall fault tolerance of the solution.

• The load balancer must pass the client's real address in the X-Real-IP or X-Forwarded-For header, and its IP address must be listed as trusted in the Altcraft configuration.

• When deploying the service in multiple instances, configure sticky sessions on the load balancer. This ensures that all requests from a single user are routed to the same instance, which prevents cache desynchronization and incorrect system behavior.

Other Options

For example, to ensure high-performance sending (millions of emails per hour), multiple MTA servers can be deployed.

info

If a server has multiple IP addresses, one of them can be used for sending via an SMTP relay by creating a dedicated sender.

And to simplify maintenance, all databases can be moved to a dedicated server and resources redistributed.

The specific scheme depends on the tasks at hand — for example, a prioritized delivery channel. Details of the optimal configuration can be clarified with the Altcraft team: support@altcraft.com.