Multi-Tenant Pub/Sub Architecture

1. Topic Isolation Pattern

We’ve implemented a sophisticated topic isolation pattern that provides several key benefits:

• Customer-Specific Topics: Each customer has dedicated publisher topics for events and user properties.

• Independent Scaling: Topics can scale individually based on customer load.

• Clear Data Boundaries: Naturally enforces data separation between customers.

• Simplified Monitoring: Enables easy tracking of per-customer metrics.

• Enhanced Security: Offers built-in data isolation at the infrastructure level.

2. Publishing Patterns

Our publishing approach ensures reliable and efficient event delivery:

• Asynchronous Publishing: Enables non-blocking event publication.

• Batch Processing: Efficiently handles bulk events before pushing them to topics. (Batch size is configurable per customer to allow modular scale)

• Retry Mechanisms: Automatically retries failed publish attempts.

• Dead Letter Queues: Captures failed topic pushes for debugging and disaster recovery.

• Event retention: Retain events for 7 days for replay of messages in case of disaster recovery.

  
  

3. Subscriber Patterns

We’ve implemented a flexible subscription model that allows various downstream systems to process events according to their needs. This multi-layer subscription setup is core to our event pipeline.

• Use Case-Based Subscriptions:

  1. Dedicated subscriber for data warehouse ingestion, optimized for batch processing and analytics.

  2. Real-time subscribers for time-sensitive tasks like agentic learning and eligibility decisions (core to Aampe’s agentic infrastructure).

• Subscription Types: We use both Push and Pull subscriptions depending on the use case.

• Monitoring and Control:

  1. Per-subscription metrics for throughput, latency, and error rates

  2. Dynamic scaling based on load

  3. Resource utilization tracking

  4. Cost management per subscription

• Subscriber retention: Retain messages for 7 days to replay for disaster recovery

  
  

Key Architectural Decisions

1. Multi-Topic vs. Single Topic

We opted for a multi-topic architecture rather than a single topic with filtering, because it provides:

• Better customer isolation

• Easier monitoring and debugging

• More granular scaling

• Clearer cost attribution

• Better compliance with data residency and governance

2. Synchronous vs. Asynchronous Processing

We rely on asynchronous processing to:

• Improve response times for webhook endpoints

• Absorb high-volume traffic spikes

• Avoid timeout issues

• Optimize resource utilization

• Increase system resilience

Monitoring and Observability

• Per-Customer Metrics: Track individual customer performance

• Processing Latency: Measure end-to-end time from ingestion to processing

• Error Rates: Monitor and alert on failures across the pipeline

• Resource Utilization: Track CPU, memory, and other key metrics

• Cost Metrics: Attribute processing costs down to the customer level

Security Considerations

Security is embedded at every layer of the architecture:

• Data Isolation: Enforced through topic and subscription design

• Authentication: Strong identity verification mechanisms

• Authorization: Fine-grained access control using JWT-based claims

• Audit Logging: Full activity logs for compliance and debugging

This architecture has proven to be highly scalable and reliable, processing millions of events each day while maintaining strict data isolation and delivery guarantees. Its separation of concerns, standardized event formats, and robust publishing mechanisms form the foundation of a resilient and future-ready event pipeline.