Thread-Coordinated Ractors: The Pattern That Delivers
summary
Shows that replacing thread-heavy JSON and CPU work with a persistent ractor pool inside Karafka delivers real wins: frozen deserialization and offloading parsing/validation yields up to 5.7x throughput on production payloads and typical results around 2x–3.5x speedup. Implementation uses an intermediate coordinating thread, nonblocking zero copy handoff, and fallback to main thread on parse errors. It ships as an opt-in Karafka feature for Ruby 4, works in production for several orgs, and fails for IO‑heavy or mutating libraries.
AI-written summary · about
chapters (10)
- 0:00Introduction to Ractors
- 4:49Why Ractors over other options
- 10:58Ractors performance breakthrough
- 14:10Ractor worker design
- 17:52Real-world data results
- 19:40Production performance gains
- 21:27Library compatibility issues
- 23:34ERB rendering with Ractors
- 25:20When not to use Ractors
- 26:25Key takeaways and future
related talks
28mRactors in Ruby 4.0: Message Passing Without the Pain
28mCome Discuss Ractors and Concurrency with 'The Dude'!
30mRactor on Ruby 3.4
25mRactor Demonstration
35mConcurrency in Ruby: Threads, Fibers and Ractors Demystified
29mUsing Ractors and Making Ractors Usable
26mConcurrency in Ruby: From fork() to Fiber
38mScaling Ruby with Actors, or How I Learned to Stop Worrying and Love Threads