DEV Community: Ankush Banyal

We're at NAB 2026 — And Here's What We've Been Building for Live Streaming at Scale

Ankush Banyal — Wed, 08 Apr 2026 11:21:05 +0000

We're going to Las Vegas 🎰

NAB Show 2026 is almost here — April 19 to 22 at the Las Vegas Convention Center — and the Ant Media team will be there.

If you are attending and working on anything related to live streaming, low latency video, IP camera infrastructure, broadcast workflows, or real-time applications — come find us at our booth. We would genuinely love to talk shop, no sales pitch required.

But before that, let me share some of what we have been working on and thinking about — because NAB is not just a conference, it is a moment to reflect on where the industry is heading.

The problem nobody talks about enough: latency vs scale

Most streaming solutions make you choose. You either get low latency or you get scale. WebRTC gives you sub-half-second latency but historically has been brutal to scale beyond a few hundred viewers. HLS scales beautifully but 8 to 10 seconds of delay makes it useless for anything interactive — auctions, live sports betting, game shows, real-time monitoring.

The thing we have been obsessing over at Ant Media is collapsing that trade-off.

Here is the architecture pattern that actually works at scale:

Publishers (OBS / hardware encoders / WebRTC)
          ↓
    Origin Cluster (ingest + stream metadata)
          ↓
    Edge Cluster (WebRTC delivery to viewers)
          ↓
    Viewers (sub-500ms latency, thousands concurrent)

The key insight is separating ingest from delivery. Origins handle publishers. Edges handle viewers. They talk to each other via a shared MongoDB cluster for stream metadata and routing. Horizontal scaling becomes trivial — add Edge nodes when viewer count grows, add Origins when publisher count grows. They never compete for the same resources.

On a c5.9xlarge (36 vCPU), a single Edge node handles roughly 800 to 830 concurrent WebRTC viewers at 720p before hitting limits. Scale math becomes predictable.

RTSP ingestion — the unsexy backbone of enterprise video

WebRTC gets all the attention. But a huge chunk of real-world video infrastructure runs on RTSP. IP cameras. VMS systems. Security feeds. Industrial monitoring. Every camera in every warehouse, factory, hospital and data center is almost certainly pushing RTSP streams somewhere.

We have been doing a lot of work on high-volume RTSP ingestion — pulling streams from cameras, transcoding or passthrough routing, and distributing to AI clusters or human viewers downstream.

A pattern we see a lot:

200 x IP Cameras (RTSP, 4K, H264)
          ↓
    Ant Media (ingest + transcode)
          ↓ ↓ ↓
    AI Cluster 1 (4K @ 15fps)
    AI Cluster 2 (1080p @ 15fps)
    AI Cluster 3 (4K @ 1fps for snapshots)

The 1fps output is the one people always underestimate. For computer vision workloads that just need periodic frame analysis rather than full video — dropping to 1fps cuts GPU load to almost nothing compared to full rate output. Small detail, big impact on server count.

SRT is quietly becoming the protocol of choice for contribution

If you work in broadcast or live production, you already know this. SRT (Secure Reliable Transport) has become the go-to for contribution links — getting video from the field into your ingest point reliably over unpredictable networks.

We support SRT ingest natively. One thing that bit us recently in a Kubernetes deployment — the default Helm chart was only exposing RTMP port 1935 through the load balancer. Port 4200 UDP for SRT was missing. If you are deploying Ant Media on AKS or any Kubernetes cluster and wondering why your SRT streams are not reaching the server, check your load balancer config and make sure 4200 UDP is exposed.

# Make sure this is in your service config
- port: 4200
  protocol: UDP
  name: srt

Small thing, but it has caught a few teams out.

Kubernetes deployments — the IP assignment question

Since we are talking about Kubernetes — this is something that comes up every single time someone deploys Ant Media on AKS in a private enterprise network.

The question is always: which components consume VNet IPs vs which ones use overlay IPs?

Here is the short answer for Azure CNI Overlay deployments:

Component	IP Type
Origin Pods	CNI Overlay IP
Edge Pods	CNI Overlay IP
MongoDB Pod	CNI Overlay IP
Ingress Controller	VNet IP
Azure Load Balancer	VNet IP
AKS Nodes	VNet IP

With hostNetwork set to false on your AMS pods, all application pods get Overlay IPs. Only the external-facing entry points consume VNet subnet IPs. This matters a lot in enterprise environments where VNet IP space is limited and carefully managed.

Also — if you are not using WebRTC (pure RTMP/SRT/HLS deployments), disable Coturn entirely. It is not needed and it adds unnecessary complexity to the IP routing.

Come talk to us at NAB

We will be at NAB Show 2026, April 19 to 22 in Las Vegas.

If you are working on:

Live streaming infrastructure at scale
Low latency WebRTC delivery
RTSP camera ingestion and distribution
AKS / cloud-native streaming deployments
Broadcast contribution workflows with SRT
AI video analytics pipelines

...come find us. We are happy to talk architecture, share what we have learned, and hear what you are building.

No forced demos. No sales scripts. Just streaming engineers talking about streaming problems. Which honestly is the best kind of conversation.

See you in Vegas 🎲

Ant Media Server is an open source and enterprise live streaming solution supporting WebRTC, RTMP, HLS, SRT, RTSP and more. antmedia.io

Evaluating Low-Latency Streaming Architectures and Protocol Evolution at NAB 2026

Ankush Banyal — Wed, 01 Apr 2026 10:26:57 +0000

The NAB Show has consistently reflected the direction of the media and streaming industry. In 2026, the focus has moved beyond incremental improvements in delivery toward structural changes in transport protocols, real-time processing, and cloud-native infrastructure.

This technical overview outlines the architectural shifts shaping modern streaming systems.

1. Transport-Layer Optimization: The Rise of MoQ

Historically, streaming optimizations were confined to the application layer. In 2026, the industry is moving down the stack to the transport layer.

Media over QUIC (MoQ)

The most significant development is the transition toward Media over QUIC. By utilizing the QUIC transport protocol, MoQ provides the low-latency benefits of WebRTC with the caching and scalability of HTTP-based delivery.

At NAB 2026, production-ready demonstrations (such as those in the West Hall) are showcasing MoQ achieving ~1s latency without the complex signaling overhead found in traditional WebRTC.

Protocol Comparison for Engineers

Protocol	Latency	Delivery Model	Primary Constraint
WebRTC	< 1s	P2P / SFU	Connection overhead at scale
LL-HLS	2–6s	Segmented	TCP head-of-line blocking
MoQ (QUIC)	~1s	Datagram/Stream	Browser implementation maturity

2. Technical Case Study: Ant Media at NAB 2026

A recurring challenge in streaming architecture is maintaining ultra-low latency while scaling horizontally. Ant Media's presence at NAB 2026 (Booth W3317) serves as a technical case study for addressing this through auto-scaling WebRTC clusters.

Key Technical Demonstrations:

Protocol Interoperability: Side-by-side comparisons of Media over QUIC (MoQ) vs. WebRTC, highlighting the reduction in server-side state management when moving to QUIC-based relays.
Auto-Scaling Infrastructure: Demonstrations of one-click, self-managed live streaming services that utilize Kubernetes to scale WebRTC nodes dynamically across multi-cloud environments (AWS, Azure, Google Cloud).
AI-Driven Workflows: Integration of AI sidecars within the Ant Media Server pipeline for real-time video processing, including automated subtitling via Speech-to-Text and Server-Guided Ad Insertion (SGAI).
Ecosystem Integration: Collaborative workflows with partners like SyncWords (AI captioning), Mobiotics (SGAI/SSAI logic), and Spaceport (Free Viewpoint Video capture), showing how modular plugins are replacing monolithic streaming engines.

3. AI as a Pipeline Primitive

AI is no longer an external post-processing step. In 2026, AI components are integrated as sidecar containers directly within the media pipeline.

Core Implementation Areas:

Neural Transcoding: Using AI models to optimize bitrate-to-quality ratios in real-time.
On-the-Fly Inference: Integrating Speech-to-Text and Translation engines as middle-layer services.
9:16 Auto-Cropping: Real-time AI tools that track players or objects in a broadcast and automatically crop 16:9 feeds for vertical mobile viewing at "true broadcast speed" (minimal induction of delay).

4. Modular and Kubernetes-Native Design

Modern architectures are defined by functional decoupling and container orchestration. The industry is moving toward "studio-in-a-box" solutions that are entirely software-defined.

The Modern Streaming Stack:

Ingest Layer: Securely handling RTMP, SRT, or WebRTC ingest via VPC endpoints.
Management Plane: Decoupled logic for stream routing and session management.
Data Plane: Specialized Kubernetes pods for transcoding and AI sidecars.
Delivery Layer: QUIC-based edge nodes or multi-CDN egress.

Cloud-Agnosticism: Standardizing on Helm charts to ensure the stack runs identically on private bare metal or public clouds.
Security: A shift toward zero-trust networking where media servers have no public IP exposure, utilizing private endpoints for all internal traffic.

5. Backend Monetization (SSAI/SGAI)

Client-side ad insertion is increasingly deprecated due to performance issues and ad-blockers.

Server-Side Ad Insertion (SSAI): The server stitches ads directly into the media segments, providing a seamless stream.
Server-Guided Ad Insertion (SGAI): A hybrid approach where the server provides precise instructions to the client, allowing for local interactivity without the overhead of client-side SDKs.

6. Technical Landscape Summary

For engineers observing the 2026 technical landscape, these areas represent the current frontier:

QUIC Interoperability: Testing how different MoQ implementations behave across browser engines.
Wasm at the Edge: Executing lightweight business logic (watermarking, authentication) at the CDN edge using WebAssembly.
K8s Operators for Video: Developing specialized Kubernetes Operators to manage the lifecycle of media-specific workloads.

Conclusion

Streaming systems are evolving into intelligent, modular ecosystems. The next generation of platforms is defined by the integration of low-latency transport, real-time AI inference, and immutable, cloud-native infrastructure.

streaming #videoengineering #architecture #quic #webrtc #cloudnative #antmedia #nabshow

While Everyone Was Buffering, Ant Media Rewrote the Rules of Live Streaming

Ankush Banyal — Wed, 25 Mar 2026 10:53:36 +0000

In a world where a single second of delay can cost you a viewer, a sale, or a life — one streaming engine decided that "low latency" wasn't low enough.

Picture this: a surgeon in Berlin is guiding a procedure happening in real time in Lagos. A sports bettor in Tokyo is watching a penalty kick that's already been decided by the time the stream reaches him. A classroom of 500 students asks their teacher a question — and waits.
In each of these scenarios, latency isn't just an inconvenience. It's the difference between useful and useless.
This is the world that Ant Media Server was built for.

The Latency Problem Nobody Solved — Until Now
For years, the streaming industry accepted a dirty compromise: either you get quality, or you get speed.
HLS, the backbone of most streaming platforms, delivers a clean picture — but carries an 8 to 10 second delay. For pre-recorded content, that's fine. For anything live and interactive, it's a disaster.
Ant Media Server took a different approach. By building its architecture around WebRTC — the same protocol that powers real-time video calls — it delivers streaming latency under 0.5 seconds. Not "almost real-time." Actual real-time.

"The biggest thing for us with Ant Media Server is the zero latency streaming service and really good support from the team."
— Verified Customer Review

Not Just Fast — Remarkably Flexible
Speed without scale is a party trick. What sets Ant Media apart is that it delivers sub-second latency at any scale — from a single IP camera feed to a global broadcast with hundreds of thousands of concurrent viewers.
The platform supports an extraordinary range of protocols out of the box:

WebRTC — real-time interactive streaming under 0.5 seconds
HLS and LL-HLS — broad compatibility and CDN delivery (8–10 seconds)
RTMP, RTSP, SRT, CMAF, WHIP/WHEP, and Zixi
Adaptive Bitrate (ABR) — automatically matches viewer bandwidth
Full SDK support — iOS, Android, Flutter, React Native, Unity, and JavaScript

Whether you are building for mobile, desktop, or embedded devices — the protocol is never the bottleneck.

The Numbers That Matter
MetricValueWebRTC Latency< 0.5 secondsHLS Latency8–10 secondsCompanies Using It2,000+Countries120+Free Trial14 days

Who Is Actually Using It?
The roster of real-world deployments tells the story better than any benchmark.
The German Red Cross uses Ant Media Server to power live aerial drone feeds during emergency rescue operations.
Mojio, a global leader in connected vehicle technology, relies on it for real-time dashcam streaming across large automotive fleets.
Financial and insurance SaaS platforms use it for eKYC and remote inspection workflows where regulatory compliance and sub-second latency are both non-negotiable.
In education, healthcare, live auctions, sports broadcasting, IP surveillance, and interactive entertainment — the use cases are as diverse as the industries themselves.

Enterprise Power, Without Enterprise Complexity
What truly separates Ant Media from the competition is not just the technology — it's the philosophy.
Deploy on AWS, Azure, Google Cloud, Oracle, or on-premise. Run it in a private cloud, an air-gapped network, or a hybrid setup. Scale horizontally with auto-managed clusters or run a single node for a focused use case. The infrastructure bends to your needs, not the other way around.
One of the most consistent themes across hundreds of verified user reviews is how surprisingly easy Ant Media Server is to set up and operate. Clear documentation, well-designed REST APIs, and a thoughtful onboarding experience mean that teams can go from trial to production without months of integration work.
Security is not an afterthought either. Token-based authentication, stream-level access control, SSL/TLS encryption, IP filtering, and watermarking are all built in — critical for industries handling sensitive content or regulated data.

The Bottom Line
The streaming landscape is crowded. But most solutions were designed for a world where "good enough" latency was acceptable, where scale meant sacrifice, and where flexibility came at the cost of simplicity.
Ant Media Server was designed for a different standard.
If you are building anything where what happens on screen needs to match what is happening in the world — in real time, at scale, on any device — there is now a clear answer to which platform you should be evaluating first.

"Streaming means Ant Media Server. What they are providing is really value for money. For every business use case they have the best plans available."
— Verified Customer Review

Get Started
🚀 Start your free 14-day trial: https://antmedia.io
📖 Quick Start Guide: https://docs.antmedia.io/quick-start/
💬 Have questions? Reach out at contact@antmedia.io

Written by Ankush Banyal, Solutions Specialist at Ant Media

The Internet is Moving Toward Real-Time — Are We Ready?

Ankush Banyal — Wed, 11 Mar 2026 10:50:37 +0000

A few years ago, most of the internet was built around static content.

You loaded a webpage.
You watched a video.
You refreshed to see updates.

Everything worked on a simple principle: request → response → wait.

But the internet is changing.

Today, users expect things to happen instantly.

Live sports with sub-second delay
Interactive classrooms where students ask questions in real time
Multiplayer gaming with voice and video
Live auctions where milliseconds matter
Creator streams where audiences react instantly

This shift is pushing the internet toward something very different:

Real-time infrastructure.

The Latency Problem

Most of the video streaming infrastructure that powers the internet today was designed for scale, not interaction.

Protocols like HLS and DASH were revolutionary when they were introduced. They allowed platforms to distribute video to millions of viewers reliably.

But they come with a trade-off.

Typical latency with HLS is:

8–30 seconds

For watching a movie, that’s perfectly fine.

For interactive experiences, it’s a problem.

Imagine:

answering a question in a live class 20 seconds late
placing a bid after the auction already closed
reacting to a goal in a football match after your friends already celebrated

As digital experiences become more interactive, latency becomes the bottleneck.

Enter WebRTC

WebRTC was originally designed for peer-to-peer communication.

It powers things like:

Google Meet
Discord voice chat
Telemedicine platforms
collaborative tools

But something interesting happened.

Developers realized WebRTC could also be used to build ultra-low-latency streaming systems.

Instead of:

10–30 seconds latency

You can achieve:

<500 milliseconds

That changes what kinds of applications become possible.

The Rise of Real-Time Platforms

We’re starting to see a new category of platforms emerging that rely heavily on real-time video infrastructure.

Some examples include:

Live commerce

Shopping streams where viewers buy products instantly.

Interactive education

Teachers and students engaging in live classes.

Gaming and esports

Real-time gameplay broadcasts with audience interaction.

Telehealth

Doctors consulting patients over video.

Live events

Concerts, conferences, and hybrid experiences.

All of these require something traditional streaming wasn’t built for:

two-way interaction at scale.

The Architecture Challenge

Building real-time video systems is not trivial.

Developers suddenly need to think about things like:

WebRTC signaling
media servers
bandwidth optimization
horizontal scaling
load balancing
real-time transport protocols

A single live event with thousands of viewers can generate enormous traffic.

For example:

5000 viewers × 1.5 Mbps = 7.5 Gbps

Handling that efficiently requires smart architecture decisions.

Many teams end up building clusters of media servers that handle:

ingest
transcoding
distribution
real-time delivery

This is where specialized streaming infrastructure platforms enter the picture.

The Developer Experience Matters

Historically, video infrastructure has been complicated.

Developers often had to deal with:

low-level media pipelines
codec tuning
complicated server deployments

The trend today is toward simplifying real-time media infrastructure.

Developers want:

simple APIs
scalable architectures
flexible deployment options
cloud-native infrastructure

Just like databases evolved from complex setups to easy cloud services, video infrastructure is undergoing the same transformation.

The Next Wave of the Internet

We’re slowly moving toward an internet that feels less like watching content and more like participating in experiences.

Instead of passive consumption, users want:

interaction
presence
immediacy

In many ways, real-time video is becoming the new user interface of the internet.

It’s already happening in:

social platforms
remote work
online education
creator economies

And we’re probably still early.

Final Thoughts

When developers talk about the future of the web, the conversation often revolves around things like:

AI
blockchain
decentralized systems

But another transformation is happening quietly in the background:

the shift toward real-time digital experiences.

The infrastructure we build today will define how people interact online tomorrow.

And increasingly, the expectation is simple:

If it’s live, it should feel instant.

LinkedIn Is Moving Beyond Kafka — And Why Platforms Like Ant Media Server Matter More Than Ever in Real-Time Streaming

Ankush Banyal — Wed, 18 Feb 2026 10:58:16 +0000

When LinkedIn — the original creator of Apache Kafka — starts rethinking its streaming architecture, it naturally grabs attention.

Kafka has powered real-time data pipelines for over a decade. It became the backbone of event-driven systems across finance, e-commerce, social platforms, and analytics. So when LinkedIn evolves beyond it, it’s not drama — it’s progress.

But here’s the part that often gets overlooked.

There’s a big difference between real-time data streaming and real-time media streaming.

And that’s where platforms like Ant Media Server quietly play a very different — and very critical — role.

Real-Time Data vs. Real-Time Media

Kafka (and similar systems) are built for event streaming:

Logs

Messages

Notifications

Clickstream data

Backend service communication

Latency here usually means milliseconds to seconds. That’s great for analytics and system coordination.

But when we talk about live sports, auctions, betting, live commerce, virtual classrooms, or interactive events — “real-time” means something completely different.

It means:

Sub-second glass-to-glass latency

Stable video delivery

Adaptive bitrate

Scaling to thousands (or millions) of viewers

Handling unpredictable network conditions

Keeping audio/video perfectly in sync

That’s not a data problem.
That’s a media infrastructure problem.

Where Ant Media Server Fits In

This is where Ant Media Server comes in.

While Kafka moves structured data between systems, Ant Media Server is built specifically for ultra-low latency audio and video delivery using WebRTC and LL-HLS.

For example:

WebRTC delivery with ~0.5 second latency

Adaptive bitrate streaming (ABR)

Horizontal scaling via clustering

Cloud or on-prem deployment

Support for large-scale concurrent viewers

In many modern architectures, you’ll actually see both working together:

Kafka (or another data pipeline) handles:

Bidding events

Chat messages

Notifications

User actions

Ant Media Server handles:

The actual live video stream

Real-time interaction

Viewer delivery at scale

Different layers of the stack. Same real-time ambition.

Why This Matters

As companies push for more immersive, interactive experiences, the definition of “real-time” keeps getting stricter.

It’s no longer enough for data to move quickly.
Users expect video and audio to feel instant.

Whether it’s a live auction where milliseconds impact bids, a sports broadcast where fans can’t tolerate delay, or a virtual classroom where interaction must feel natural — media latency becomes the business differentiator.

That’s where specialized real-time media servers become essential.

The Bigger Picture

LinkedIn evolving beyond Kafka doesn’t mean Kafka failed. It means scale and requirements evolve.

The same applies to media streaming.

As use cases become more interactive and latency-sensitive, companies increasingly look beyond traditional CDN-only models and adopt WebRTC-based infrastructure platforms like Ant Media Server to achieve true low-latency delivery.

Real-time isn’t one technology.
It’s a layered architecture.

And as the stack evolves, both data pipelines and real-time media platforms have their place.

The future of streaming won’t be built on one tool.
It will be built on the right combination of tools — working together.

Designing Video Architecture That Scales With Your Product (Not Against It)

Ankush Banyal — Wed, 18 Feb 2026 10:57:10 +0000

If you’re building a modern app with video, chances are your requirements didn’t stop at “just a video call.”

It usually starts simple:

One-to-one video calls
Then evolves into:

Live streaming

Audience interaction

Real-time gifts, reactions, overlays

That’s when architecture choices start to matter — a lot.

This article walks through how teams typically handle private video calls and interactive live streaming in the same product, what works well in practice, and where things usually break.

Two Video Use Cases That Look Similar — But Aren’t

At a glance, these both involve video:

Private one-to-one calls

One-to-many live broadcasts with interaction

Under the hood, they behave completely differently in terms of:

Bandwidth

Latency

Scaling

Infrastructure cost

Trying to force one solution to handle both almost always leads to compromises.

One-to-One Video Calls: P2P Still Wins

For private calls, the goals are clear:

Lowest possible latency

Direct communication

Minimal backend involvement

The Practical Setup (Still Valid in 2025)

WebRTC peer-to-peer for audio/video

Backend only for signaling, auth, and discovery

STUN + TURN (coturn) for NAT/firewall reliability

This setup has aged well because it does exactly what it should:

Media flows directly when possible

Falls back gracefully when networks get messy

Keeps infrastructure costs predictable

For 1:1 calls, routing media through your backend is usually unnecessary overhead.

Why P2P Doesn’t Scale for Live Streaming

Live streaming changes everything.

If one broadcaster has:

50 viewers

100 viewers

500 viewers

Pure P2P means the broadcaster uploads that many streams.

On mobile, that’s a hard no:

Battery drain

Upload limits

Dropped frames

Crashes under load

This is where many early-stage apps hit their first real wall.

SFU: The Missing Middle Layer

To scale live video properly, you need a Selective Forwarding Unit (SFU).

The idea is simple:

Broadcaster uploads one stream

SFU forwards it efficiently to viewers

Latency stays low

The broadcaster’s device survives

This model is why SFUs power most real-time live platforms today.

Gifts, Reactions, and Why Latency Matters

Live gifts only feel meaningful if:

The broadcaster reacts instantly

Viewers see reactions in sync

Latency stays very low

This is where traditional RTMP → HLS pipelines struggle:

15–30 seconds of delay kills interaction

Gifts feel disconnected from reality

That’s why many teams combine:

WebRTC (via SFU) for interactive viewers

HLS / LL-HLS for large, passive audiences

It’s not either/or — it’s choosing the right tool per audience size.

Running 1:1 Calls and Live Rooms in the Same App

This is a common concern, and yes — it works well if you keep boundaries clear.

What Can Be Shared

Authentication

User identity

Payments and gifting logic

Chat, reactions, UI components

What Should Stay Separate

Media routing paths

Scaling logic

Session lifecycle handling

Trying to reuse the exact same media flow for everything usually leads to tight coupling and painful refactors later.

Where Platforms Like Ant Media Fit In

When teams don’t want to build and maintain all of this from scratch, they often look for solutions that already support multiple streaming models.

For example, platforms like Ant Media Server are commonly used in setups where:

WebRTC P2P is needed for private calls

WebRTC SFU is needed for interactive live streams

HLS or LL-HLS is needed for scale

Mobile clients are first-class citizens

The value isn’t just protocol support — it’s having one backend that can handle different video paths cleanly, depending on the use case.

Whether you build yourself or use an existing platform, the architecture principles stay the same.

Common Mistakes Teams Regret Later

Some patterns show up again and again:

Forcing P2P to handle live broadcasts

Adding gifts on top of high-latency streams

Ignoring TURN usage until production bills arrive

Testing only on good Wi-Fi

Over-optimizing for massive scale too early

Most of these come from trying to simplify too much.

If I Were Starting Fresh Today

I’d design with intent from day one:

WebRTC P2P for private calls

WebRTC SFU for live, interactive streams

HLS / LL-HLS only when scale demands it

Gifts and reactions built as real-time events

Clear separation between call logic and broadcast logic

It’s not the smallest setup — but it’s one that grows without fighting you.

Final Thought

Video isn’t hard because of codecs or APIs.

It’s hard because:

Latency shapes user behavior

Mobile networks are unpredictable

Different use cases need different paths

Get the architecture right early, and everything else — features, scale, monetization — becomes much easier.

Hopefully this saves someone a painful rewrite down the road.