Part 3: Real-World Code
From concepts to production
Everything we just covered — pattern matching, processes, supervision, LiveView — these aren't academic concepts. They're the foundation of production systems running real businesses right now. Let's walk through three real systems built at Vianet Management.
Three Production Systems
Going beyond basic Web apps
Vianet Marketing — Email marketing platform
OrbitFour — full featured domain registration platform
Vianet Admin — Multi-site LiveView dashboard
We'll look at three systems. Each one showcases different aspects of what we learned — GenServers, supervision, pattern matching, and LiveView — all in production.
Vianet Marketing
Sending emails through AWS Simple Email Service (SES)
First system: our Vianet marketing platform. This sends half a million personalized emails through AWS SES. The challenge isn't just volume — it's doing it reliably without exceeding rate limits.
This is our Vianet marketing platform. On the left you can see the campaign details — audience, member count, schedule. On the right, the actual email preview. Over half a million members, and each one gets a personalized email.
The Challenge
Send 500,000+ personalized marketing emails
Emails need to be sent individually so each one is trackable.
Ensure we send one and only one email per recipient!
Handle bounces, complaints, and delivery notifications
Each email generates 3–4 API requests — needs to run concurrently without blocking the app
With AWS SES, if you exceed your rate limit, they... silently drop your emails .
Here's what makes this hard. Each email has to be sent individually so we can track opens, clicks, and bounces per recipient. We have to guarantee one and only one email per person — duplicates destroy trust. We need to handle bounces, complaints, and delivery notifications from AWS. Each email generates 3 to 4 API requests, so this has to run concurrently without blocking the web app. And the kicker: if you exceed your AWS SES rate limit, they silently drop your emails. No error, no warning, nothing. So we need a rate limiter that's rock-solid.
Our Solution
Scheduler Worker queries recipients, creates Oban jobs
Oban picks up each job and triggers a Mailer Worker
Mailer Worker validate → personalize → rate-check → send
Rate Limiter ensures we never exceed the AWS SES limit
Here's our solution. A scheduler worker queries recipients and creates individual Oban jobs — one per email. Oban is an Elixir job queue backed by Postgres, it picks up each job and triggers a mailer worker. Each mailer worker handles one email through a pipeline: validate, personalize, check the rate limiter, send. And the rate limiter is a GenServer that ensures we never exceed the AWS SES sending rate. Everything is supervised.
Scheduling 500k Jobs
Stream records in chunks — constant memory usage
def perform(%Oban.Job{args: args}) do
member_ids = Campaigns.member_ids!(args["campaign_id"])
# Stream from DB → chunk → bulk insert jobs
Repo.transaction(fn ->
Repo.stream(member_ids(campaign), max_rows: 2_000)
|> Stream.chunk_every(2_000)
|> Enum.each(fn member_ids ->
member_ids
|> Enum.map(&build_mailer_job(&1, campaign))
|> Oban.insert_all()
end)
end, timeout: :infinity)
end
You can't load 500k records into memory at once. Repo.stream gives us a lazy stream — a database cursor that fetches rows lazily. Stream.chunk_every breaks it into chunks of 2,000. Each chunk becomes 2,000 individual email jobs inserted into Oban. Constant memory usage regardless of how many records we have. The Repo.transaction wrapper is required because the database cursor needs the connection to stay open for the full iteration.
The Mailer Worker
Pattern matching handles every possible failure
def perform(%Oban.Job{args: args} = job) do
campaign_id = Map.get(args, "campaign_id")
member_id = Map.get(args, "member_id")
with(
{:ok, member} <- get_member_with_site(member_id),
{:ok, _} <- validate_email(member.email),
{:ok, campaign} <- get_campaign_with_site(campaign_id),
{:ok, _} <- EmailRateLimiter.ready?()
) do
send_campaign_email(campaign, member)
else
{:not_ready, :exceeded_rate} -> {:snooze, 1}
{:already_sent} -> {:discard, :already_sent}
{:invalid_email} -> {:discard, :invalid_email}
{:error, result} -> {:error, result}
end
end
Each email goes through a pipeline using the `with` chain we saw in LiveBook. Get the member, validate the email, get the campaign, reserve a campaign email record to guarantee exactly-once delivery, then check the rate limiter. If everything passes, send. The else block reads like a specification: rate exceeded? Snooze 1 second. Daily limit hit? Back off up to an hour. Already sent? Discard. Invalid email? Discard. Every outcome is handled explicitly. No silent failures.
The Rate Limiter
A GenServer using a token bucket algorithm
defmodule Marketing.EmailRateLimiter do
use GenServer
defstruct tokens: 0.0, rate: 100.0
# Public API — other code just calls this
def ready?, do: GenServer.call(__MODULE__, :acquire)
def handle_call(:acquire, _from, state) do
if state.tokens >= 1.0 do
{:reply, {:ok, :token}, %{state | tokens: state.tokens - 1.0}}
else
{:reply, {:not_ready, :exceeded_rate}, state}
end
end
end
This is the real rate limiter, simplified for the slide. It's a GenServer using a token bucket algorithm. The public API is just `ready?` — that's all other code needs to call. Internally, it tracks tokens that refill over time based on our SES sending rate. When a worker asks ready?, it refills tokens based on elapsed time, then checks if there's a token available. If yes, it decrements and says OK. If not, it says not ready. Thread-safe by design — the GenServer processes messages one at a time, so there's no way two workers can grab the same token.
OrbitFour Domain Registry
Taking ownership of our core functions
Second system: OrbitFour, our domain registrar. This is a story about taking ownership of your core functions — and how Elixir made that practical.
This is OrbitFour — our domain registrar. Clean, simple interface. No upselling, no cross-sells. Let's look at what's under the hood.
What is OrbitFour?
A domain registrar — think GoDaddy, but built by a small team in West Michigan.
Talks directly to Verisign via persistent TCP — EPP protocol
Full lifecycle: search → register → DNS → renew → transfer
Billing, RDAP/WHOIS, customer portal, marketing site — all one Phoenix app
16 background workers — syncing, renewals, health checks
OrbitFour is Vianet's domain registrar. Customers search for a domain, buy it, manage DNS, renew it — the whole lifecycle. Under the hood, it talks directly to Verisign over a persistent TCP connection. And here's what's impressive: one Phoenix app handles everything. EPP protocol, RDAP and WHOIS public APIs, Stripe billing, DNS zone management, a full LiveView customer portal, the marketing website, and 16 background workers. In most stacks, this would be 4 or 5 separate services. Here it's one app, one deployment, one supervision tree.
The Core Function
OrbitFour is a domain registrar and needs to communicate with registries like Verisign via EPP as our core function .
Originally an open-source PHP EPP library was used.
Open-source is great for non-core features.
We needed to own the protocol layer: persistent TCP/TLS, connection pooling, automatic recovery
Elixir made this possible — the BEAM was literally built for managing network connections.
OrbitFour is a domain registrar. Talking to Verisign over EPP is the single most important thing the app does. Originally we relied on an open-source PHP EPP library — it worked, but we didn't fully understand it, and when things broke we were at the mercy of upstream. Using open-source for non-core features is smart — but when the feature IS your product, you need to own it. Elixir made this realistic. The BEAM was designed for exactly this kind of work: persistent TCP connections, connection pooling, automatic recovery. We could write our own EPP client and actually understand every line.
This is our EPP Health Monitor — a LiveView page that shows the connection pool status in real-time. You can see the persistent TCP connections to PublicInterest and Verisign, utilization, response times. Stats refresh every 5 seconds. This is what owning your core function looks like.
The Real Win
OrbitFour replaced five separate services with one Elixir app
PHP EPP service — domain registration
Java RDAP service — domain lookups
PHP WHOIS service — WHOIS queries
Craft CMS — marketing site
Nuxt/Vue.js — customer portal
These services took years to build originally.
With Elixir + Claude Code, we replaced them all in under six months .
Here's the real story with OrbitFour. The original system was five separate services across three languages and two frameworks. A PHP EPP service for domain registration, a Java RDAP service for lookups, a PHP WHOIS service, a Craft CMS marketing site, and a Nuxt/Vue.js customer portal. These took years to build and maintain. With Elixir and Claude Code, we consolidated everything into a single Phoenix app in under six months. One codebase, one deployment, one supervision tree. That's the power of the platform.
Internal Admin
Multi-site LiveView dashboard
Third system: our internal admin app. This is a LiveView dashboard that connects to all of Vianet's properties from a single place.
This is our internal admin app. Here you're looking at the photo review queue for Roommates.com — one dashboard to manage all of Vianet's properties.
The Philosophy
Instead of building admin features into each app...
Customer apps stay focused — no admin routes, no admin UI, no admin auth
Admin app iterates fast — internal tool, no public-facing risk
One dashboard — manage all sites from a single place
LiveView — real-time updates, interactive tables, presence tracking
The philosophy: instead of polluting each customer-facing app with admin features, we built a separate admin app that connects to all of them. Customer apps stay clean. The admin app can iterate fast since it's internal. One dashboard to manage everything. And LiveView gives us real-time updates for free.
Multi-Database Architecture
Connects to five databases simultaneously. Each Repo is a supervised connection pool to a different PostgreSQL database.
defmodule VianetAdmin.Application do
use Application
def start(_type, _args) do
children = [
VianetAdmin.Repo, # Admin's own database
VianetAdmin.PuppiesRepo, # Puppies.com database
VianetAdmin.RRRepo, # ReputableRooms database
VianetAdmin.RoommatesRepo, # Roommates database
VianetAdmin.GeocodeRepo, # Geocoding database
VianetAdmin.ConnectionMonitor,
VianetAdmin.Presence, # ← Track which admins are online
]
opts = [strategy: :one_for_one, name: VianetAdmin.Supervisor]
Supervisor.start_link(children, opts)
end
end
Here's the admin app's supervision tree. It connects to five PostgreSQL databases simultaneously — each Repo is a supervised connection pool. Plus a connection monitor and presence tracking to see which admins are online. If any database connection drops, the supervisor handles it automatically. This is a simplified version — the full tree has more children, but this shows the pattern.
What We Covered
Why Elixir? — The BEAM, 40 years of reliability
The Language — Pattern matching, processes, supervision, LiveView
Real-World Code — marketing emails, a domain registrar, multi-site admin
Concurrency is the default , not an afterthought
Errors are handled by design , not by hope
Real-time features come for free
It's a different paradigm — and once it clicks, it's hard to go back.
Quick recap. Why Elixir: the BEAM, 40 years of telecom reliability. The language: pattern matching, processes, supervision, and LiveView — all hands-on. Real production code: half a million emails, a domain registrar consolidated from five services, a multi-site admin dashboard. The key takeaway: concurrency, fault tolerance, and real-time features aren't libraries you bolt on — they're built into the language. It's a fundamentally different way to build web applications, and once it clicks, it's really hard to go back.
Getting Started
If you want to get started: elixir-lang.org has excellent official guides. Install Livebook tonight and start experimenting. Phoenix is the web framework. The Elixir Forum is genuinely one of the friendliest communities in tech. And Elixir School has free, self-paced lessons.
Thank You
Torey Heinz
Vianet Management / Shopflow
github.com/toreyheinz/2026-GR-WebDevElixirTalk
Questions?
Thank you! I'm happy to take questions. If you want to chat more about Elixir, catch me after — I could talk about this stuff all day.