Transmute Engine by Seresa: Security Architecture Documentation

Tech Spec security Transmute Engine
October 21, 2025
by Cherry Rose

Technical Overview for Data Security Managers – Version: 1.0

Document Purpose

This document details the technical security architecture of Transmute Engine ™ by Seresa, including data retention policies, automated deletion mechanisms, access controls, and infrastructure isolation options.

System Overview

Platform: Node.js v22
Database: MongoDB with TTL indexes
Architecture: Ephemeral data processing pipeline
Data Model: Event-based, short-term retention only

Transmute Engine processes analytics events and routes them to configured third-party integrations (GA4, Facebook Pixel, etc.) – we call these outPIPE’s.

The system is designed for minimal data persistence with automated, database-level deletion.

Data Retention Policy

Successful Events

  • Retention Period: Maximum 60 minutes after successful delivery to all configured integrations
  • Deletion Mechanism: MongoDB TTL index with expireAfterSeconds: 3600
  • Trigger: allDelivered field populated upon successful delivery to all endpoints

Failed Events

  • Retention Period: Maximum 48 hours from initial event timestamp
  • Deletion Mechanism: MongoDB TTL index with expireAfterSeconds: 172800
  • Trigger: Applied to events with deliveryStatus containing “pending” or “failed” states

Guaranteed Deletion

  • TTL monitor runs every 60 seconds as MongoDB background thread
  • Operates independently of application health
  • Cannot be disabled or delayed by application code
  • Continues functioning during system failures or maintenance

Technical Implementation: MongoDB TTL Indexes

TTL Index 1: Delivered Events

db.events.createIndex(
  { "allDelivered": 1 }, 
  { 
    expireAfterSeconds: 3600,
    partialFilterExpression: {
      "allDelivered": { $exists: true }
    }
  }
)

Function: Targets documents where all configured integrations have successfully received the event.

Behavior:

  • Documents deleted when allDelivered + 3600 seconds < current_time
  • Only affects documents with allDelivered field present
  • Partial index reduces index size and improves performance

TTL Index 2: Unsent/Failed Events

db.events.createIndex(
  { "timestamp": 1 }, 
  { 
    expireAfterSeconds: 172800,  // 48 hours
    partialFilterExpression: {
      $or: [
        { "deliveryStatus.*.status": "pending" },
        { "deliveryStatus.*.status": "failed" }
      ]
    }
  }
)

Function: Targets events that failed delivery attempts or remain pending after retry logic exhaustion.

Behavior:

  • Documents deleted when timestamp + 172800 seconds < current_time
  • Only affects documents matching partial filter expression
  • Ensures failed events don’t persist indefinitely

Why TTL Indexes

Database-Level Enforcement: Deletion logic exists in MongoDB core, not application code. This prevents:

  • Deletion bypasses through code bugs
  • Retention extension through developer error
  • Manual intervention to preserve data

Operational Independence: TTL monitor operates as separate MongoDB thread. Continues functioning during:

  • Application crashes
  • Deployment cycles
  • System maintenance
  • Network interruptions

Audit Trail: TTL operations logged in MongoDB metrics (db.serverStatus().metrics.ttl) for compliance verification.

Data Flow and Retry Logic

Successful Delivery Path

  1. Event received via WordPress plugin
  2. Event stored with TTL index on timestamp field (48-hour failsafe)
  3. Parallel delivery to all configured integrations
  4. Upon all successful deliveries: allDelivered field set to current timestamp
  5. First TTL index (delivered events) takes precedence
  6. Event deleted within 60 minutes

Failure Handling Path

Immediate Retry (0-60 seconds):

  • 3 retry attempts within first minute
  • Exponential backoff: 5s, 15s, 30s intervals
  • Most transient failures resolved in this window

Dead Letter Queue (1-48 hours):

  • Events failing initial retries moved to DLQ
  • Additional 3 retry attempts distributed over 48 hours
  • Retry intervals: 6 hours, 24 hours, 47 hours
  • Allows recovery from extended third-party outages

Final Deletion (48 hours):

  • Events still undelivered after all retry attempts permanently deleted via TTL index
  • No archival, no backup retention
  • Failure statistics updated (counts only, no event data)

Access Control Architecture

Engineering Team Access

Permitted:

  • System health metrics via external monitoring APIs
  • Aggregate error counts and delivery success rates API only
  • Server resource utilization API only (CPU, memory, disk)
  • Application logs via API only (sanitized, no PII)

Prohibited (and no engineer access) :

  • Direct database queries containing event data
  • Event payload content
  • Customer PII (names, emails, transaction details)
  • Individual event inspection or debugging with real data

Technical Enforcement

  • Database access restricted to application service accounts
  • No direct shell access to production database servers
  • Query logs monitored for unauthorized access patterns
  • Application logs configured to exclude event payload data

Infrastructure Isolation: Dedicated Servers

Available On: Premium and Enterprise plans

Architecture

Shared Infrastructure (Standard Plans):

  • Single and multi-tenant server environment application servers
  • Shared MongoDB instances with logical database separation
  • Sufficient for most use cases with proper data lifecycle management

Dedicated Infrastructure (Premium+ Plans):

  • Single-tenant server environment
  • Dedicated MongoDB instance
  • Isolated processing queues and memory space
  • No resource sharing with other clients

Security Benefits

Data Isolation: Event data never coexists with other customers’ data—not in memory, processing queues, or storage.

Attack Surface Reduction: Breach of one client’s application logic cannot access another client’s data.

Compliance: Satisfies data residency and isolation requirements for regulated industries (healthcare, finance, government).

Performance Consistency: No resource contention from other clients’ high-volume periods.

Use Cases

  • Healthcare: HIPAA compliance requirements
  • Finance: PCI-DSS data isolation mandates
  • Enterprise: Internal security policy requirements
  • Government: Data sovereignty regulations

Self-Healing Architecture

Automated Recovery Mechanisms

Health Monitoring:

  • Continuous process health checks
  • Memory leak detection
  • Unhandled exception monitoring
  • Third-party integration availability tracking

Automatic Restart Logic:

  • Critical service failures trigger immediate restart
  • Exponential backoff for repeated failures
  • Circuit breaker patterns for failing third-party integrations
  • Prevents cascade failures

Recovery Procedures:

  • Event processing queue restoration from last known state
  • Retry logic resumes from last checkpoint
  • TTL indexes continue operation regardless of application state

Security Implications

  • Reduces manual intervention requirements
  • Minimizes engineer access to production systems
  • Maintains data deletion schedules during incidents
  • Prevents data accumulation during extended outages

Compliance and Audit

Data Minimization

System design inherently supports GDPR Article 5(1)(c) – data minimization principle:

  • Only data necessary for integration delivery is collected
  • Retention limited to operational necessity (max 48 hours)
  • No secondary data usage or analysis

Right to Erasure

Due to automatic deletion:

  • Most erasure requests satisfied automatically within 60 minutes (successful events)
  • Failed events erased within 48 hours maximum
  • No long-term storage requiring manual deletion procedures

Data Processing Records

Available for audit:

  • TTL deletion metrics from MongoDB
  • Aggregate delivery success/failure statistics
  • System uptime and recovery events
  • Access control logs

Not Available (by design):

  • Individual event content logs
  • Long-term event archives
  • Customer data backups

Security Considerations for Evaluation

Strengths

✅ Automated Deletion: Database-level TTL removes human error
✅ Minimal Retention: 60-minute maximum for successful processing
✅ Zero Engineering Access: Technical enforcement prevents PII exposure
✅ Dedicated Infrastructure: Available for enhanced isolation
✅ Self-Healing: Reduces manual intervention and access requirements

Limitations

⚠️ 48-Hour Failure Window: Failed events retained up to 48 hours for retry logic
⚠️ Third-Party Delivery: Data security depends on integration endpoint security after delivery
⚠️ Shared Infrastructure: Standard plans use multi-tenant architecture (mitigated by TTL)

Risk Assessment

Data Breach Risk: Low

  • Minimal retention window reduces exposure
  • TTL ensures data doesn’t accumulate
  • No long-term storage to compromise

Data Loss Risk: Medium

  • Failed events deleted after 48 hours (acceptable for analytics data)
  • No backup retention by design
  • Client assumes risk for unrecoverable delivery failures

Compliance Risk: Low

  • Automated deletion supports data minimization requirements
  • No long-term retention to manage
  • Clear data lifecycle for audit purposes

Technical Specifications Summary

ComponentSpecification
RuntimeNode.js v22
DatabaseMongoDB with TTL indexes
Successful Event Retention60 minutes maximum
Failed Event Retention48 hours maximum
TTL Monitor FrequencyEvery 60 seconds
Retry Attempts (Initial)3 within 60 seconds
Retry Attempts (DLQ)3 over 48 hours
Engineering Data AccessMetrics only, no PII
Dedicated InfrastructurePremium+ plans
Self-HealingAutomated restart and recovery

Questions for Security Review

  1. Data Classification: What is the sensitivity classification of analytics event data in your organization?
  2. Retention Requirements: Do you have minimum data retention requirements that conflict with automatic deletion?
  3. Compliance Mandates: Are there specific regulatory frameworks (HIPAA, PCI-DSS, GDPR) requiring dedicated infrastructure?
  4. Incident Response: What are your requirements for forensic analysis in case of security incidents?
  5. Third-Party Risk: What is your process for evaluating security of integration endpoints (GA4, Facebook, etc.)?

Contact for Technical Security Questions

For detailed technical discussions, architecture reviews, or compliance documentation:

Security Team: security@seresa.io
Technical Documentation: docs.seresa.io
Compliance Inquiries: support@seresa.io

Evaluation: 3-Day Technical Trial

Trial Includes:

  • Full access to Premium features including dedicated server option
  • Complete API documentation and integration guides
  • Technical support for security team evaluation
  • Compliance documentation package

No Credit Card Required

Start Technical Evaluation →

This document is maintained by Seresa security engineering. Last reviewed: October 20, 2025

Share this post
Related posts