Fair by design: orchestrating background jobs in Ruby

by Alexander Baygeldin

Embed

Start on current slide

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Alexander Baygeldin, Evil Martians Fair by design: orchestrating background jobs in Ruby 🍕🍕🍕

Slide 4

Slide 4 text

PENTAGON

Slide 5

Slide 5 text

🧑🍳 🧑🍳 🧑🍳

Slide 6

Slide 6 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕

Slide 7

Slide 7 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕

Slide 8

Slide 8 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕

Slide 9

Slide 9 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕

Slide 10

Slide 10 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕

Slide 11

Slide 11 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 Latency = the time between placing the order and starting to prepare it

Slide 12

Slide 12 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🧑🍳 🧑🍳

Slide 13

Slide 13 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🧑🍳 🧑🍳 🧢 🧢 part-time chefs

Slide 14

Slide 14 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🧑🍳 🧑🍳 🧢 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 part-time chefs

Slide 15

Slide 15 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🧑🍳 🧑🍳 🧢 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 🧑🍳 🧢 part-time chefs At some point improving Quality of Service at more operational cost leads to diminishing returns

Slide 16

Slide 16 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕

Slide 17

Slide 17 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕

Slide 18

Slide 18 text

🍕 🍕 🍕 🧑🍳 🧑🍳 🧑🍳

Slide 19

Slide 19 text

🧑🍳 🧑🍳 🧑🍳 The greater the latency, the greater the need to treat customers fairly 🍕 🍕

Slide 20

Slide 20 text

G = n ∑ i=1 n ∑ j=1 xi − xj 2n2 ¯ x = n ∑ i=1 n ∑ j=1 xi − xj 2n n ∑ i=1 xi 𝒥 (x1 , x2 , …, xn ) = (∑n i=1 xi )2 n ⋅ ∑n i=1 xi 2 = x2 x2 = 1 1 + ̂ cv 2 Jain's index? Gini index? Some other guy's index?

Slide 21

Slide 21 text

How do we know if we're not? ☑ FIFO queue ☑ High latency ☑ Greedy users Are we OK?

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 24

Slide 24 text

🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 25

Slide 25 text

🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 26

Slide 26 text

🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 27

Slide 27 text

🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 28

Slide 28 text

🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 29

Slide 29 text

🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 30

Slide 30 text

🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 31

Slide 31 text

🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 32

Slide 32 text

🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 33

Slide 33 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕

Slide 34

Slide 34 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕

Slide 35

Slide 35 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🎲

Slide 36

Slide 36 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🎲 🍕 🍕 🍕 🍕 🍕

Slide 37

Slide 37 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🎲 🍕 🍕 🍕 🍕 🍕

Slide 38

Slide 38 text

🧑🍳 🧑🍳 🧑🍳 BRPOP queue:tenant_1 queue:tenant_2 ... queue:tenant_N 2 timeout per-tenant queues

Slide 39

Slide 39 text

🧑🍳 🧑🍳 🧑🍳 LMOVE queue:tenant_1 queue:sq||tenant_1 RIGHT LEFT LMOVE queue:tenant_2 queue:sq||tenant_2 RIGHT LEFT ... LMOVE queue:tenant_N queue:sq||tenant_N RIGHT LEFT worker's "in-progress" queues per-tenant queues

Slide 40

Slide 40 text

🧑🍳 🧑🍳 🧑🍳 Solid Queue SELECT DISTINCT(queue_name) FROM solid_queue_ready_executions WHERE queue_name LIKE 'tenant_%'

Slide 41

Slide 41 text

🧑🍳 🧑🍳 🧑🍳 Solid Queue SELECT job_id FROM solid_queue_ready_executions WHERE queue_name = 'tenant_N' ORDER BY priority ASC, job_id ASC LIMIT ? FOR UPDATE SKIP LOCKED

Slide 42

Slide 42 text

🧑🍳 🧑🍳 🧑🍳 GoodJob 👍 WITH rows AS MATERIALIZED ( SELECT id, active_job_id FROM good_jobs WHERE queue_name = 'tenant_N' AND () ORDER BY priority DESC NULLS LAST, created_at ASC LIMIT ? ) SELECT id FROM rows WHERE pg_try_advisory_lock() LIMIT 1

Slide 43

Slide 43 text

🧑🍳 🧑🍳 🧑🍳

Slide 44

Slide 44 text

Thinking about building your own background job processor Actually building one

Slide 45

Slide 45 text

(with what we have) 1. Shuf fl e-sharding 2. Interruptible iteration 3. Throttling 4. Per-tenant queues Let's fix this!

Slide 46

Slide 46 text

🍕 🍕 🍕 🍕 🍕 🍕 🧑🍳 🧑🍳 🧑🍳

Slide 47

Slide 47 text

🍕 🍕 🍕 🍕 🍕 🍕 Alex 🍕 Amy 🍕 Joe 🍕 Sam 🍕 Sam 🍕 Amy 🍕 A to I J to R S to Z 🧑🍳 🧑🍳 🧑🍳

Slide 48

Slide 48 text

🧑🍳 🧑🍳 🧑🍳 Alex 🍕 Amy 🍕 Joe 🍕 Sam 🍕 Sam 🍕 Amy 🍕 A to I J to R S to Z

Slide 49

Slide 49 text

🧑🍳 🐷 Pentagon 🍕 🧑🍳 🧑🍳 Amy 🍕 Amy 🍕 Sam 🍕 🐷 Pentagon 🍕 A to I J to R S to Z

Slide 50

Slide 50 text

🧑🍳 🐷 Pentagon 🍕 🧑🍳 🧑🍳 Amy 🍕 Amy 🍕 Sam 🍕 🐷 Pentagon 🍕 A to I J to R S to Z

Slide 51

Slide 51 text

🧑🍳 🐷 Pentagon 🍕 🧑🍳 🧑🍳 A to I J to R S to Z Amy 🍕 🐷 Pentagon 🍕 💤 Joe 🍕

Slide 52

Slide 52 text

🧑🍳 🐷 Pentagon 🍕 🧑🍳 🧑🍳 A to I J to R S to Z Amy 🍕 🐷 Pentagon 🍕 Joe 🍕 J to R

Slide 53

Slide 53 text

🧑🍳 🐷 Pentagon 🍕 🧑🍳 🧑🍳 A to I J to R S to Z Amy 🍕 🐷 Pentagon 🍕 Joe 🍕 J to R Sam 🍕

Slide 54

Slide 54 text

🧑🍳 🐷 Pentagon 🍕 🧑🍳 🧑🍳 A to I J to R S to Z Amy 🍕 🐷 Pentagon 🍕 Joe 🍕 J to R Sam 🍕 A to I S to Z

Slide 55

Slide 55 text

Shuffle-sharding TL;DR: good when you have enough workload to fi ll all shards. No hogging? No—but it's less likely by a factor of . Perfectly fair? No—but it affects fewer people when it's not fair. Full resource utilization? Usually, yes—unless there are too many shards. Does it scale? Yes—in fact, it gets more effective.

Slide 56

Slide 56 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕

Slide 57

Slide 57 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕 🍕 🍕

Slide 58

Slide 58 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕

Slide 59

Slide 59 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 💤 💤 💧

Slide 60

Slide 60 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 💤 💤 💧

Slide 61

Slide 61 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕 🍕 🍕

Slide 62

Slide 62 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 63

Slide 63 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕 🍕

Slide 64

Slide 64 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕 🍕

Slide 65

Slide 65 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕 🍕 🍕 🍕 🍕 🍕 🍕 🍕

Slide 66

Slide 66 text

Interruptible iteration No hogging? No—it could happen if one tenant enqueues too many batches simultaneously. Perfectly fair? No—it stops being fair when someone hogs the queue. Full resource utilization? Usually, yes—except when there are less than jobs in the queue. Does it scale? Yes—using cursors to track progress is cheap. TL;DR: good when the workload comes in large batches.

Slide 67

Slide 67 text

🧑🍳 🧑🍳 🧑🍳 🍕

Slide 68

Slide 68 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕

Slide 69

Slide 69 text

🪣 🚿 🕳

Slide 70

Slide 70 text

🪣 🚿 🕳 💧 💧 💧 💧 💧 💧 💧 💧 💧 over time, the bucket leaks allowing further orders bucket has a limited capacity each new order fi lls the bucket

Slide 71

Slide 71 text

🪣 🚿 🕳 💧 💧 💧 💧 💧 💧 💧 💧 💦 💦 uh-oh, over fl ow! bucket has a limited capacity each new order fi lls the bucket over time, the bucket leaks allowing further orders

Slide 72

Slide 72 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕

Slide 73

Slide 73 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕 excess orders are put here

Slide 74

Slide 74 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕 🎲

Slide 75

Slide 75 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕 🎲 default queue (80% chance to be chosen) throttled queue (20% chance to be chosen)

Slide 76

Slide 76 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🍕 🍕 🎲 default queue (80% chance to be chosen) throttled queue (20% chance to be chosen) 🍕

Slide 77

Slide 77 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🎲 default queue (80% chance to be chosen) throttled queue (20% chance to be chosen) 🍕

Slide 78

Slide 78 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🎲 🍕 orders stuck in the throttled queue :(

Slide 79

Slide 79 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕 🎲 🍕

Slide 80

Slide 80 text

🧑🍳 🧑🍳 🧑🍳 🍕 🎲 🍕 no longer throttled (100% chance to be chosen)

Slide 81

Slide 81 text

Throttling No hogging? Yes—everyone will get at least a little work done. Perfectly fair? No—especially if the workload is bursty by nature. Full resource utilization? Yes—with weighted queues support. Does it scale? Yes—especially with leaky buckets. TL;DR: good when the workload is well distributed over time.

Slide 82

Slide 82 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕

Slide 83

Slide 83 text

🧑🍳 🧑🍳 🧑🍳 🍕 🍕

Slide 84

Slide 84 text

🧑🍳 🧑🍳 🧑🍳 🍕 👨💼 🍕 📒

Slide 85

Slide 85 text

🧑🍳 🧑🍳 🧑🍳 🍕 👨💼📒 🍕

Slide 86

Slide 86 text

🧑🍳 🧑🍳 🧑🍳 🍕 👨💼📒 🍕 💤

Slide 87

Slide 87 text

🧑🍳 🧑🍳 🧑🍳 👨💼📒 🍕 ‼

Slide 88

Slide 88 text

🍕 🍕 📒 🧑🍳 🧑🍳 🧑🍳 👨💼 🍕 🍕 🍕

Slide 89

Slide 89 text

🧑🍳 🧑🍳 🧑🍳 👨💼📒 🍕 🍕 🍕 💤 bottleneck? 🤨

Slide 90

Slide 90 text

🧑🍳 🧑🍳 🧑🍳 📒 🍕 🍕 🍕 👨💼 🧙

Slide 91

Slide 91 text

🧑🍳 🧑🍳 🧑🍳 📒 🍕 🍕 🍕 🧙

Slide 92

Slide 92 text

🧑🍳 🧑🍳 🧑🍳 📒 🍕 🍕 🍕 🧙

Slide 93

Slide 93 text

🍕 🍕 🍕 🎲 🍕 🍕 🍕 🍕 🍕 🧑🍳 🧑🍳 🧑🍳 📒 🍕 🍕 🍕 🧙

Slide 94

Slide 94 text

Slide 95

Slide 95 text

Per-tenant queues + custom scheduler No hogging? Yes—it's basically communism. Perfectly fair? Yes—as fair as you care to make it. Full resource utilization? Yes—with zero changes to the underlying infra. Does it scale? Usually, yes—unless the scheduler is slower than workers. TL;DR: good when the workload is heavy enough to forget about the bottleneck.

Slide 96

Slide 96 text

✨ AI work fl ows ⬇ Data imports 📊 Report generation 🖼 Media processing (where fairness matters) Examples! ` ... and more!

Slide 97

Slide 97 text

✨ AI work fl ows ⬇ Data imports 📊 Report generation What limits throughput?

Slide 98

Slide 98 text

✨ AI work fl ows ⬇ Data imports 📊 Report generation What limits throughput? I/O wait

Slide 99

Slide 99 text

✨ AI work fl ows ⬇ Data imports 📊 Report generation I/O wait API rate limits Database GPU* * if self-hosted What limits throughput?

Slide 100

Slide 100 text

When a scarce resource is shared, fairness becomes a requirement.

Slide 101

Slide 101 text

So, which one? Shuf fl e- sharding Interruptible iteration Throttling Per-tenant queues No hogging? ❌ ❌ ✅ ✅ Perfectly fair? ❌ ❌ ❌ ✅ Full resource utilization? 🟧 🟧 ✅ ✅ Does it scale? ✅ ✅ ✅ 🟧

Slide 102

Slide 102 text

evilmartians.com/chronicles baygeldin/sidekiq-fairplay Envek/sidekiq-fair_tenant palkan/faqueue Resources