Skip to main content

Smart Scaling: Leveraging Cloud HA and Prioritizing Your Recorder for Cost-Effective Performance

· 5 min read
Jibon L. Costa
Jibon L. Costa
Founding developer

When building any critical application, "scalability" and "high availability" (HA) are often top of mind. But for many, these terms conjure images of complex, multi-node clusters, expensive infrastructure, and a steep learning curve. The truth is, for most plugNmeet users, achieving both performance and resilience can be much simpler and more cost-effective than you might think.

This article will demystify the relationship between scalability and HA, and guide you through a pragmatic, phased approach to optimizing your plugNmeet deployment. We'll show you how to leverage the power of your cloud provider for HA, and why separating your recording server is almost always your first and best step towards true scalability.

Scalability vs. High Availability: Understanding the Difference​

While often used interchangeably, scalability and high availability address distinct challenges:

  • Scalability: The ability of a system to handle a growing amount of work by adding resources. For plugNmeet, this means handling more concurrent users, more rooms, or more recordings.
  • High Availability (HA): The ability of a system to remain operational and accessible even if some components fail. This is about minimizing downtime and ensuring continuous service.

Leveraging Cloud Provider HA: Don't Re-Invent the Wheel​

Many users deploy plugNmeet on cloud platforms like AWS, Google Cloud, Azure, or DigitalOcean. These providers offer robust, built-in High Availability features for their virtual machines and underlying infrastructure.

  • Automatic Restarts: If a virtual machine fails, the cloud provider will often automatically restart it on healthy hardware.
  • Managed Databases: Services like managed MySQL/MariaDB or Redis often come with built-in replication and failover, ensuring your data layer is resilient.
  • Redundant Networking: Cloud networks are designed with redundancy to minimize single points of failure.

The takeaway: For many plugNmeet users, the "HA" of their server instance is already handled by their cloud provider. You might not need to build complex application-level HA for your plugnmeet-server if your underlying VM is already highly available. Focus your efforts where they matter most.

plugNmeet's Pragmatic Scaling Strategy​

Instead of immediately jumping to a complex, multi-node HA setup for plugNmeet itself, we recommend a phased approach that prioritizes impact and cost-effectiveness.

Phase 1: Separate the Recorder (The #1 Priority for Scalability)​

This is the most impactful and cost-effective step for improving your plugNmeet deployment's scalability and performance.

  • The Problem: Recording is a CPU-intensive task. Running the recorder on the same server as your live media server (plugnmeet-server + LiveKit) can starve the media server of resources, leading to poor quality for live participants.
  • The Solution: Deploy the plugnmeet-recorder on a separate, dedicated server.
  • Cost-Effective: This recorder server doesn't need to be expensive or highly available. It can be a smaller, cheaper VM. From our testing, a 2-vCPU server can handle approximately 2-3 simultaneous recordings, depending on the number of webcams active in the session. If the recorder server goes down, recordings might be temporarily delayed, but your live meetings remain unaffected. NATS JetStream's queue worker pattern ensures that recording jobs will simply wait for an available recorder to pick them up.

Phase 2: Vertical Scaling (More Power for Your Main Server)​

Once your recorder is isolated, the next step is often to simply give your main plugnmeet-server more power. A single plugNmeet setup can handle hundreds of concurrent users on a good server, so it's wise to start with a reasonable configuration and scale up as needed.

  • The Strategy: Start with a solid baseline and upgrade your main server's resources based on observed load. Prioritize increasing CPU/RAM and network bandwidth. For example, if you start with a 1 Gbps uplink and notice bottlenecks, upgrading to a 2 Gbps or 5 Gbps connection is a simple and highly effective scaling tactic.
  • The Benefit: plugNmeet and LiveKit, being written in Go, are incredibly efficient. A single, well-provisioned server can handle hundreds of concurrent users. This is far simpler and cheaper than managing a multi-node cluster.

Phase 3: Horizontal Scaling (When You Really Need It)​

Only after you've isolated the recorder and vertically scaled your main server to its practical limits should you consider a multi-node, horizontally scaled plugNmeet deployment. This is for extreme scale or custom HA requirements beyond what your cloud provider offers.

  • The Strategy: Deploy multiple plugnmeet-server instances behind a load balancer, and potentially cluster LiveKit and NATS.
  • The Benefit: This provides maximum resilience and capacity for thousands of concurrent users.
  • The Caveat: This is significantly more complex and should only be pursued when your usage patterns clearly demand it.

Conclusion: Smart Choices for Optimal Performance​

Achieving a high-performing and resilient plugNmeet deployment doesn't always mean building the most complex architecture from day one. By making smart, phased decisions, you can optimize for both cost and performance:

  1. Leverage your cloud provider's built-in HA for your server instances.
  2. Prioritize separating your recording server on a cheaper, dedicated VM to immediately boost live meeting quality.
  3. Vertically scale your main server before considering horizontal scaling.

This pragmatic approach ensures you get the most out of plugNmeet without unnecessary complexity or expense, allowing you to grow intelligently.

Ready to optimize your plugNmeet deployment?