Get the Senior Elixir role at DockYard.

mount/3 runs once for the initial static HTTP render (so first paint and SEO work without JS), then again after the WebSocket connects. Guard expensive work (subscriptions, heavy loads) with connected?(socket) so it only runs on the stateful connection. Then handle_params/3 runs (and again on every live_patch), and render/1 re-runs whenever tracked assigns change.

Only assigns that change. At compile time LiveView splits the template into static and dynamic parts; it sends the static structure once, then on each update sends only the changed dynamic values by position — the "diff." If an assign's value is unchanged, that subtree is skipped entirely. Don't pull assigns into local variables in a way that defeats change tracking — access @assign directly.

Function components are stateless — just functions returning HEEx, no process, no state. Use them for presentational reuse. LiveComponents are stateful: own assigns, their own update/2 and handle_event/3, addressed by id. They isolate state and events but still run inside the parent LiveView's process — they are not separate processes. Default to function components unless you truly need encapsulated state.

Streams render large or append-only collections without keeping the whole list in socket assigns (which bloats memory and diffs). stream/3 tracks items by DOM id and sends insert/update/delete operations instead of re-diffing the entire list. They replaced :temporary_assigns for lists — perfect for chat logs, feeds, and big tables.

PubSub for broadcasting changes: subscribe in mount when connected?, broadcast on events, handle the message in handle_info/2. Phoenix.Presence (PubSub + CRDTs) for who's online: Presence.track in mount, handle the presence_diff in handle_info. Presence merges cleanly across nodes and netsplits.

allow_upload/3 in mount sets constraints (accept, max_entries, max_file_size). The client chunks the file over the channel; you get progress events for free. consume_uploaded_entries/3 in your save handler moves files to permanent storage. With the :external option you can do direct-to-S3 uploads via presigned URLs so bytes never touch your server.

Check assigns size first — are you stuffing big structs/lists in? Move lists to streams. Verify change tracking isn't being defeated by template variables. Use liveSocket.enableDebug() in the browser console to watch diffs, and LiveDashboard to inspect the process. Watch for assigns being needlessly reassigned on every event.

Each connection is a supervised process. On a network drop the JS client auto-reconnects with backoff and re-mounts — so mount must be idempotent and able to rebuild state. If the LiveView process crashes, the supervisor restarts it and the client re-mounts. That's why irreplaceable state lives in the DB / a GenServer / ETS, never only in the socket.

call is synchronous: the caller blocks for a reply with a timeout (default 5s). Use it for reads or when you need confirmation/backpressure. cast is fire-and-forget — no reply, no backpressure. Default to call; cast silently hides overload because nothing slows the sender down when the server falls behind.

handle_call/3 handles synchronous requests (reply with {:reply, val, state}). handle_cast/2 handles async ones. handle_info/2 handles everything else the process receives — raw send, monitor :DOWN, timeouts, PubSub messages. Forgetting a catch-all handle_info clause crashes the server on an unexpected message.

A link is bidirectional and fatal — if either process dies the other gets an exit signal (and dies too, unless trapping exits). That's how supervision trees propagate failure (start_link). A monitor is one-way and non-fatal — you get a :DOWN message but survive. Use a monitor when you want to know another process died without dying with it.

:one_for_one — restart only the crashed child. :one_for_all — restart all children (when they depend on each other). :rest_for_one — restart the crashed child and any started after it (ordered deps). Plus restart intensity (max_restarts / max_seconds): crash too often and the supervisor itself gives up and escalates. Children are :permanent, :temporary, or :transient.

Don't write defensive code for every weird state. Code the happy path; if something truly unexpected happens, let the process crash and let the supervisor restart it to a known-good initial state — no corrupt state lingers. You still handle expected errors (like {:error, changeset}) explicitly. "Let it crash" is for the unexpected, not for control flow.

init/1 runs synchronously inside the supervisor's start sequence — a slow init blocks the whole tree from booting. Do minimal setup, then defer heavy work by returning {:ok, state, {:continue, :load}} and doing the load in handle_continue/2. That's the proper tool (the old send(self(), :init) trick is obsolete).

It processes one message at a time, so a single GenServer serializes everything. If reads dominate, move state to ETS so readers bypass the process entirely (the GenServer owns the table; clients read directly). For parallelism, partition into many processes (e.g. Registry + DynamicSupervisor per entity), or offload work to Task so the server stays responsive.

DynamicSupervisor starts children on demand at runtime (one process per chat room/session). Registry lets you look processes up by an arbitrary key. The {:via, Registry, {MyReg, key}} tuple names a GenServer by a dynamic key so you can call it without tracking its pid. Together they're the standard "process per entity" pattern.

A changeset captures a set of changes plus validation rules and any errors. cast/4 whitelists allowed fields (stops mass-assignment), validate_* add rules, and constraints (unique_constraint, foreign_key_constraint) defer to the database's own guarantees and turn DB errors into changeset errors. It cleanly separates "what the user sent" from "what's valid to persist," and is reused for insert and update.

cast/4 takes external, untrusted params (form strings), casts them to the schema's types, and only permits listed fields. change/2 takes already-trusted, correctly-typed data and applies it directly with no permitting/casting. Forms → cast; internal defaults or computed fields → change.

Use preload — either Repo.preload/2 after fetching, or preload: in the query so Ecto batches a second query (or joins). The N+1 trap is touching an unloaded association inside a loop, firing one query per row. In GraphQL/LiveView contexts, Dataloader batches the same way.

Multi composes several operations into one atomic transaction with named steps that can depend on earlier results. If any step fails, everything rolls back and you get {:error, failed_step, changeset, changes_so_far} — telling you exactly where it broke. Use it for "create user + profile + audit log" where partial success is unacceptable. Cleaner and far more testable than nested manual rollbacks.

Queries are just data — write functions that take a queryable and return a refined one:

def active(query), do: from u in query, where: u.active

User |> active() |> by_org(id) |> Repo.all()

This keeps query logic DRY and testable, and you compose fragments instead of duplicating where clauses everywhere.

optimistic_lock/1 adds a version field; on update Ecto checks it matches and increments it — a stale concurrent update raises Ecto.StaleEntryError so you refetch/retry. For uniqueness races, rely on a DB unique index + unique_constraint — never check-then-insert in app code (that's a TOCTOU race). For counters, use atomic update_all with inc:.

Repo.get/3 fetches by primary key, get_by/3 by clause — returning the struct or nil. Repo.one/2 expects exactly one (raises if more). Repo.all/2 returns a list. Bang versions (get!, one!) raise Ecto.NoResultsError instead of returning nil — handy with action_fallback to turn a missing record into a 404 automatically.

Migrations are versioned and run in order — keep them reversible. For zero-downtime: add columns nullable first, backfill in batches, then add constraints — never lock a huge table in one shot. Don't mix schema and data changes in one migration; do data migrations separately so they can't block a deploy. Use concurrent index creation on big tables.

A GenServer serializes access — every read and write queues behind one process, a bottleneck under heavy concurrent reads. ETS lets readers hit memory directly, in parallel. Common pattern: a GenServer owns the table (so it survives), but clients read straight from ETS. Keep state in the GenServer only when access is low-volume or you need strict ordering/coordination.

Types: :set (unique keys), :ordered_set (sorted, range scans), :bag / :duplicate_bag (multiple values per key). Concurrency: read_concurrency: true (many readers), write_concurrency: true (concurrent writers to different keys). Access: :protected (owner writes, all read — default), :public, :private. Picking these wrong silently kills performance.

The process that creates it owns it. When the owner dies the table is destroyed — unless ownership is handed off (give_away) or a heir is set. That's why a long-lived supervised GenServer should own it, so a transient crash doesn't wipe your cache. Named tables let other processes reference it by atom.

Store {key, value, expires_at}. On read, treat expired entries as misses. Sweep periodically with a GenServer timer using select_delete, or delete lazily on access. In production, reach for Cachex or Nebulex — they give TTL, LRU eviction, and stats out of the box instead of reinventing it.

Messages between processes are copied (no shared heap), so passing huge maps/lists repeatedly is expensive. Large binaries (>64 bytes) are refcounted and shared off-heap, which helps. Keep hot data in ETS (read in place) or pass ids instead of payloads. Building giant terms in one process's heap also raises GC pressure.

Measure first: :telemetry + LiveDashboard, :observer for process/memory counts, and find the process with a huge mailbox — that's your bottleneck. Profile with eprof/fprof, microbenchmark with benchee. Common fixes: move reads to ETS, partition a hot GenServer, batch DB calls, stop copying large terms.

The BEAM is preemptive: each process gets a budget of "reductions" (roughly function calls) before it's paused so others run — one busy process can't starve the rest. That's why Elixir stays responsive under load. Long native calls (NIFs) can break this fairness because they don't yield, which is why dirty schedulers exist.

When you need durability (ETS is gone on node restart — use the DB / DETS / Mnesia), when data must be consistent across nodes (ETS is node-local — use Redis / a distributed store), or when volume is low and a GenServer is simpler. ETS also has no built-in eviction — unbounded growth is a memory leak, so you always need an expiry strategy.

Oban persists jobs in Postgres, so they survive restarts and crashes — a Task or GenServer-held job is lost if the node dies. Oban also gives retries with backoff, scheduling, uniqueness, rate limiting, per-queue concurrency, and observability. Use a Task only for fire-and-forget work you can afford to lose; use Oban when the job must not be lost.

A worker has max_attempts; on failure (a raise or {:error, _}) Oban reschedules with exponential backoff (overridable via backoff/1). After max attempts it's discarded. Returning {:cancel, reason} stops retrying immediately for permanent failures (e.g. the record was deleted). Make jobs idempotent — they can run more than once.

Use unique job options, e.g. unique: [period: 60, keys: [:user_id]]. Oban blocks inserting a duplicate within the period based on the chosen fields/keys — that's how you avoid enqueuing two "welcome email" jobs for one user. Note this is about insertion, not perfect exactly-once execution — so still keep handlers idempotent.

Separate queues per concern (parsing, ai, email) each with its own concurrency, so a slow stage can't starve others. Chain steps by having each worker enqueue the next on success, passing ids (not big payloads) in args. Broadcast progress over PubSub so a LiveView shows status. Each step retries independently; use {:cancel, _} for unrecoverable errors.

Queue concurrency limits workers per queue per node. Oban Pro and plugins add global and per-key rate limiting (e.g. per customer). You can also lower max_attempts and lengthen backoff. For strict external limits, a dedicated rate-limited queue or a token-bucket check inside the worker prevents bursts.

Oban: discrete, persisted jobs you enqueue (emails, reports, scheduled tasks tied to your app). Broadway: continuous high-throughput ingestion from a data source (SQS, RabbitMQ, Kafka, GCP PubSub) with built-in batching, backpressure, and concurrency. Pulling from a broker at scale → Broadway. Enqueuing units of deferred work → Oban.

Broadway is built on GenStage: producers only fetch as many messages as downstream demand allows, so a slow processor naturally throttles the producer (backpressure) instead of overflowing memory. Batchers group messages by size/time so you can do bulk operations — one DB insert for 100 rows, one API call — instead of one at a time.

Idempotency first — guard re-runs with unique constraints / upserts. Keep args minimal (ids, not blobs). Watch queue depth, failures, and latency via Oban's telemetry + the Web dashboard. Set sane max_attempts and backoff. Isolate slow/risky work in its own queue so it can't block critical jobs, and alert on growing queues and discarded jobs.