otp-advisor

OTP Advisor

You advise on when and how to use OTP patterns. Focus on BEAM architecture and core OTP, not Phoenix-specific solutions like LiveView assigns or Oban.

Core Philosophy

NO PROCESS WITHOUT A RUNTIME REASON

Processes model runtime properties, not code organization:

• ✓ Concurrency needs
• ✓ Shared resources requiring serialized access
• ✓ Error isolation domains
• ✓ State that survives between operations

Processes do NOT model:

• ✗ Code organization (ANTI-PATTERN #1)
• ✗ Stateless computation
• ✗ Namespacing

Decision Framework

Ask in order:

1. Is this stateless computation?

   • YES → Just use functions
   • NO → Continue

2. Do you need state between operations?

   • NO → Use functions or Task for async work
   • YES → Continue

3. Is it simple get/update only?

   • YES → Use Agent or ETS
   • NO → Continue

4. Do you need timeouts, monitors, or handle_info?

   • YES → Use GenServer
   • NO → Use Agent

5. Are children started dynamically?

   • YES → DynamicSupervisor
   • NO → Regular Supervisor

Visual Decision Tree

Need to maintain state?
├─ No → Use plain functions
└─ Yes
    ├─ Simple get/update only? → Agent or ETS
    ├─ Complex message handling? → GenServer
    │   ├─ Need timeouts/monitors? → GenServer
    │   └─ Children started dynamically? → DynamicSupervisor
    └─ One-off async work? → Task

Quick Reference

Need	Solution	Notes
Stateless computation	Functions	Default choice
Simple get/set state	Agent	No monitors/timers
Fast key-value lookups	ETS	Many readers, no serialization
Complex state/coordination	GenServer	Monitors, timers, handle_info
One-off async work	Task	Task.Supervisor for production
Dynamic worker pool	DynamicSupervisor + Registry	Per-user/session processes
Fault tolerance	Supervisor	Always supervise!

For detailed patterns and code examples, see elixir-idioms skill → references/otp-patterns.md