Viitata Tenancy Infrastructure

Executive Summary

This memo documents the strategic architecture migration for Viitata from a single-tenant-per-instance model to a multi-tenant architecture on Heroku. This migration addresses critical operational inefficiencies, enables deployment of the new Viitata version with its required worker architecture, and significantly reduces both current costs and the cost of scaling while eliminating DevOps friction for client onboarding.

Key Changes:

• Architecture: Single-tenant-per-instance → Multi-tenant shared infrastructure
• Platform: Heroku (no change)
• Application Version: Current (single worker) → New version (3 workers required)
• Cost Impact: $96/month currently → $288/month if upgraded on single-tenant → $130/month on multi-tenant
• Cost Savings: 55% reduction vs. deploying new version on single-tenant architecture

Introduction

Purpose

This document outlines the rationale, technical approach, and benefits of migrating Viitata from a distributed single-tenant-per-instance model to a consolidated multi-tenant architecture on Heroku.

Scope

This memo covers:

• Current single-tenant-per-instance architecture on Heroku
• New Viitata version requirements (3-worker architecture)
• Proposed multi-tenant architecture on Heroku
• Cost analysis and operational benefits
• Technical considerations and trade-offs

Out of scope:

• Detailed application code changes for multi-tenancy
• Specific Heroku configuration details
• Data migration procedures and implementation timeline

Audience

This document is intended for technical leadership, DevOps engineers, and stakeholders involved in infrastructure planning and decision-making.

Background

Current State: Single-Tenant-Per-Instance on Heroku

Viitata currently operates with a single-tenant-per-instance model on Heroku, consisting of:

Infrastructure per Tenant:

• 1 Heroku application instance (single worker)
• 1 PostgreSQL database
• 1 Redis cache instance
• Cost: ~$16/month per tenant

Current Deployment:

• 6 production instances running current Viitata version
• Each instance operates as a single-worker application
• Total monthly cost: ~$96 (6 instances × $16)
• Each instance requires independent CI/CD pipeline
• Each instance requires separate DevOps configuration

Important Note: The current architecture runs an older version of Viitata that does not require the 3-worker architecture. However, the new version of Viitata cannot be deployed without this infrastructure change.

Challenges with Current Architecture

1. Cost Scalability Concerns

With 6 production tenants at $16/month each, the current architecture costs approximately $96/month. While manageable at this scale, the cost scales linearly with each new tenant ($16 per additional tenant). More critically, the new version of Viitata requires a 3-worker architecture that would triple costs to approximately $288/month for the same 6 tenants.

2. DevOps Friction

Each new client onboarding requires:

• Provisioning new Heroku application
• Configuring new PostgreSQL database
• Setting up new Redis cache
• Configuring CI/CD pipeline
• Managing environment variables and secrets
• Setting up monitoring and logging

This creates substantial friction and delays in client onboarding.

3. CI/CD Maintenance Overhead

Maintaining 6 separate CI/CD pipelines creates:

• Increased complexity in deployment processes
• Higher risk of configuration drift
• Difficulty in applying updates uniformly
• Additional testing burden across instances

4. Blocking Issue: New Viitata Version Requirements

The new version of Viitata fundamentally requires three distinct worker types to function:

• Web worker: Handles HTTP requests
• Celery worker: Processes asynchronous tasks
• Celery Beat worker: Manages scheduled tasks and periodic jobs

This is not optional - the new Viitata version cannot be deployed without all three workers running.

Under the single-tenant model, deploying the new version would require:

• 18 total worker processes (6 instances × 3 workers)
• Tripling of infrastructure costs per tenant (from $16 to ~$48 per tenant)
• Total monthly cost increase from $96 to approximately $288/month
• 18 separate processes to monitor and manage

Critical Impact: The single-tenant architecture makes it economically and operationally prohibitive to deploy the new version of Viitata. Without migrating to multi-tenant, the platform cannot evolve.

Technical Analysis

Proposed Architecture: Multi-Tenant on Heroku

The new architecture consolidates all tenants into a single shared Heroku infrastructure:

Shared Infrastructure:

• 1 Heroku application (supporting 3 worker types)
• 1 Heroku PostgreSQL database (with tenant isolation)
• 1 Heroku Redis cache (with tenant namespacing)
• Estimated cost: ~$130/month total

Worker Configuration:

• 1 web worker (serving all tenants)
• 1 Celery worker (processing tasks for all tenants)
• 1 Celery Beat worker (managing schedules for all tenants)
• Total: 3 workers supporting all tenants

Cost Analysis

Key Insights:

• Current architecture cannot run the new Viitata version without significant cost increase
• New version’s 3-worker requirement would triple single-tenant costs ($96 → $288)
• Multi-tenant architecture enables new version deployment at 55% lower cost than single-tenant upgrade
• Marginal cost advantage: Adding tenant #7 costs $0/month (vs. $48/month in single-tenant)
• Cost efficiency improves with scale: 10 tenants = $13/tenant, 20 tenants = $6.50/tenant

Benefits

1. Cost Reduction

• 83% reduction in infrastructure costs
• Costs remain flat as tenant count grows (until scaling threshold)
• Predictable cost model

2. Operational Efficiency

• Single CI/CD pipeline for all tenants
• Unified deployment process
• Consistent configuration across all tenants
• Reduced maintenance overhead

3. Client Onboarding

• Near-instant tenant provisioning (database record vs. full infrastructure)
• Minimal DevOps involvement
• Faster time-to-value for new clients
• Reduced onboarding friction

4. Enables New Viitata Version Deployment

• Supports required 3-worker architecture (web, Celery, Celery Beat)
• 3 shared workers support all tenants (vs. 18 separate workers in single-tenant)
• Makes new version economically viable to deploy
• Simplified monitoring and management
• Better resource utilization
• Easier to scale horizontally when needed

Technical Considerations

Data Isolation

• Tenant identification at application layer
• Row-level security in PostgreSQL
• Redis key namespacing by tenant ID
• Careful query design to prevent data leakage

Performance

• Shared resources require proper resource allocation
• Connection pooling for database efficiency
• Caching strategies to prevent tenant interference
• Monitoring to identify tenant-specific performance issues

Security

• Tenant isolation at application and data layers
• Secure tenant context management
• Audit logging for compliance
• Regular security reviews of multi-tenant code paths

Scalability

• Horizontal scaling when single instance reaches capacity
• Database sharding if needed for very large tenant counts
• CDN and edge caching for static assets
• Load balancing across multiple application instances

Trade-offs

Advantages

• Dramatic cost reduction
• Simplified operations
• Faster client onboarding
• Better resource utilization
• Easier maintenance and updates

Disadvantages

• Tenant isolation complexity in application code
• Potential “noisy neighbor” issues
• Database restore impact: Currently, database snapshots can be restored per-tenant without affecting other clients. In multi-tenant architecture, a database restore would affect all tenants simultaneously, making it impossible to roll back a single client’s data due to a bug or data issue
• More complex deployment rollback scenarios
• Requires careful tenant-aware code design
• Less isolation between tenants compared to separate instances

Risk Mitigation

• Comprehensive testing of tenant isolation
• Resource limits per tenant
• Monitoring and alerting for anomalies
• Gradual migration approach
• Ability to isolate problematic tenants if needed
• Database restore mitigation:
  • Implement application-level point-in-time recovery per tenant
  • Maintain granular database backups with tenant-specific restore capabilities
  • Use transaction logs to selectively restore tenant data
  • Establish procedures for tenant-specific data rollback without full database restore
  • More rigorous testing and staging processes to prevent production data issues
  • Consider automated daily tenant-level logical backups (pg_dump per tenant)

Conclusion

The migration from a single-tenant-per-instance architecture to a multi-tenant architecture on Heroku represents a strategic necessity for Viitata’s evolution. This change delivers:

• Enables deployment of new Viitata version with required 3-worker architecture
• 55% cost reduction vs. deploying new version on single-tenant ($288/month → $130/month)
• Dramatic reduction in operational complexity (6 CI/CD pipelines → 1, 18 workers → 3)
• Near-zero marginal cost for new tenants ($0 vs. $48/tenant in single-tenant)
• Improving cost efficiency at scale: Cost per tenant decreases as platform grows
• Eliminates DevOps friction in client onboarding

Without this migration, deploying the new version of Viitata would nearly triple costs while adding significant operational burden. The multi-tenant architecture not only makes the new version economically viable but also positions Viitata for sustainable growth with costs that improve with scale.

While multi-tenancy introduces complexity in application design around tenant isolation and data security, the alternative—remaining on single-tenant architecture—would either block the platform’s evolution or make it financially unsustainable. The operational benefits, cost savings, and improved scalability make this migration essential for Viitata’s future.

References

• Heroku Pricing
• Heroku Dynos and Scaling
• Celery Documentation
• PostgreSQL Row Level Security
• Multi-Tenant SaaS Architecture Patterns