How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Multi-step rollback — Automation Mastery

Day 27 · ~12 min●

A pipeline with three side-effecting steps either completes all three or — if any step fails — undoes the ones that succeeded. "Either fully done or fully reverted" is a transaction. The pattern works without a real database transaction by tracking what's been done and inverting it on failure.

python

completed = []                     # log of (step_name, action_to_undo)

def undo(action_log):
    for step_name, undo_fn in reversed(action_log):
        try:
            undo_fn()
        except Exception as e:
            print(f"undo failed for {step_name}: {e}")

state = {"x": 0, "y": 0, "z": 0}

try:
    state["x"] = 1
    completed.append(("step1", lambda: state.update({"x": 0})))

    state["y"] = 2
    completed.append(("step2", lambda: state.update({"y": 0})))

    raise RuntimeError("step 3 failed")

    state["z"] = 3
    completed.append(("step3", lambda: state.update({"z": 0})))
except Exception as e:
    print(f"caught: {e}; rolling back")
    undo(completed)

print(state)

Expected: {'x': 0, 'y': 0, 'z': 0}. The two completed steps got reversed; step 3 never happened.

Why reversed?

Last-in-first-out. If step 2 depends on step 1 having succeeded, undoing step 1 before step 2 could leave the system in a worse state than before step 1. Reverse order matches the dependency reverse.

And what if an undo itself fails?

That's the gnarly bit. Three options:

Log it and continue — best-effort rollback; surface unrecovered state for human review
Stop the rollback — leave the rest in flight; alert hard
Mark for retry — queue the failed undo, try again later

For today's lesson: option 1. A failed undo is itself a kind of dead-letter; it lands in a list and you fix it later.

Multi-step rollback — best-effort transaction emulation

Why this matters

Real databases give you transactions: BEGIN; ...; COMMIT or ROLLBACK. If anything fails between BEGIN and COMMIT, the database undoes everything for you.

Cross-tool pipelines have no such mechanism. Sending an email, creating a Sheet row, posting to Calendar — each is committed independently. If step 3 fails, steps 1 and 2 are already done.

The rollback pattern emulates a transaction at the application layer: track what you did, undo on failure.

The pattern

python

completed = []

def do_with_undo(name, do_fn, undo_fn):
    do_fn()
    completed.append((name, undo_fn))

try:
    do_with_undo("step1", do_step1, undo_step1)
    do_with_undo("step2", do_step2, undo_step2)
    do_with_undo("step3", do_step3, undo_step3)
except Exception:
    for name, undo_fn in reversed(completed):
        try:
            undo_fn()
        except Exception:
            log("warn", "undo_failed", step=name)
    raise

Building the undo

For each side-effecting step, define its inverse:

Action	Undo
Append a row to a Sheet	Mark the row's status as `reverted` (or delete)
Create a Calendar event	Delete the event by `event_id`
Send an email	(no real undo — see below)
Charge a card	Issue a refund
Set state["k"] = v	Set state["k"] = previous value

Most actions have a real inverse. Sending an email doesn't — once sent, it's sent. For irreversible actions, see below.

Irreversible actions

When a step has no real undo:

Position it last — do all reversible steps first; do the irreversible one only when you're confident the rest succeeded
Send a compensating message — "the previous email was sent in error; please disregard" (clunky, but better than silence)
Pre-flight validation — verify everything the step depends on before doing it

The rule: irreversible steps go after the verification gates and after the reversible steps. Minimize the window in which an irreversible action can happen alongside an unrecovered reversible step.

Logging the rollback

A rollback is itself an event you want recorded:

python

log("info", "pipeline_failed", step=failed_step, error=str(e))
log("info", "rollback_start", completed_steps=len(completed))
for name, undo_fn in reversed(completed):
    log("info", "undo", step=name)
    try:
        undo_fn()
    except Exception as e:
        log("error", "undo_failed", step=name, error=str(e))
log("info", "rollback_done")

Saga pattern (production-grade)

The production version of this is the saga pattern: a long-running business transaction broken into compensable steps. Frameworks like Temporal, Camunda, and AWS Step Functions implement sagas natively.

For a script, the explicit completed log + reversed rollback is enough. The shape is the same; the framework does the persistence.

What this lesson does NOT cover

Deliberately out of scope:

Persistent saga state across crashes (production saga frameworks)
Idempotent undo operations (so retrying an undo is safe — same primitive as elsewhere)
Distributed coordination (multiple workers running steps)

Those are framework territory. The application-layer pattern — log what you did, undo in reverse — is what carries through.

Day 27 · ~12 min●

python

completed = []                     # log of (step_name, action_to_undo)

def undo(action_log):
    for step_name, undo_fn in reversed(action_log):
        try:
            undo_fn()
        except Exception as e:
            print(f"undo failed for {step_name}: {e}")

state = {"x": 0, "y": 0, "z": 0}

try:
    state["x"] = 1
    completed.append(("step1", lambda: state.update({"x": 0})))

    state["y"] = 2
    completed.append(("step2", lambda: state.update({"y": 0})))

    raise RuntimeError("step 3 failed")

    state["z"] = 3
    completed.append(("step3", lambda: state.update({"z": 0})))
except Exception as e:
    print(f"caught: {e}; rolling back")
    undo(completed)

print(state)

Expected: {'x': 0, 'y': 0, 'z': 0}. The two completed steps got reversed; step 3 never happened.

Why reversed?

Last-in-first-out. If step 2 depends on step 1 having succeeded, undoing step 1 before step 2 could leave the system in a worse state than before step 1. Reverse order matches the dependency reverse.

And what if an undo itself fails?

That's the gnarly bit. Three options:

Log it and continue — best-effort rollback; surface unrecovered state for human review
Stop the rollback — leave the rest in flight; alert hard
Mark for retry — queue the failed undo, try again later

For today's lesson: option 1. A failed undo is itself a kind of dead-letter; it lands in a list and you fix it later.

Multi-step rollback — best-effort transaction emulation

Why this matters

Real databases give you transactions: BEGIN; ...; COMMIT or ROLLBACK. If anything fails between BEGIN and COMMIT, the database undoes everything for you.

Cross-tool pipelines have no such mechanism. Sending an email, creating a Sheet row, posting to Calendar — each is committed independently. If step 3 fails, steps 1 and 2 are already done.

The rollback pattern emulates a transaction at the application layer: track what you did, undo on failure.

The pattern

python

completed = []

def do_with_undo(name, do_fn, undo_fn):
    do_fn()
    completed.append((name, undo_fn))

try:
    do_with_undo("step1", do_step1, undo_step1)
    do_with_undo("step2", do_step2, undo_step2)
    do_with_undo("step3", do_step3, undo_step3)
except Exception:
    for name, undo_fn in reversed(completed):
        try:
            undo_fn()
        except Exception:
            log("warn", "undo_failed", step=name)
    raise

Building the undo

For each side-effecting step, define its inverse:

Action	Undo
Append a row to a Sheet	Mark the row's status as `reverted` (or delete)
Create a Calendar event	Delete the event by `event_id`
Send an email	(no real undo — see below)
Charge a card	Issue a refund
Set state["k"] = v	Set state["k"] = previous value

Most actions have a real inverse. Sending an email doesn't — once sent, it's sent. For irreversible actions, see below.

Irreversible actions

When a step has no real undo:

Position it last — do all reversible steps first; do the irreversible one only when you're confident the rest succeeded
Send a compensating message — "the previous email was sent in error; please disregard" (clunky, but better than silence)
Pre-flight validation — verify everything the step depends on before doing it

Logging the rollback

A rollback is itself an event you want recorded:

python

log("info", "pipeline_failed", step=failed_step, error=str(e))
log("info", "rollback_start", completed_steps=len(completed))
for name, undo_fn in reversed(completed):
    log("info", "undo", step=name)
    try:
        undo_fn()
    except Exception as e:
        log("error", "undo_failed", step=name, error=str(e))
log("info", "rollback_done")

Saga pattern (production-grade)

For a script, the explicit completed log + reversed rollback is enough. The shape is the same; the framework does the persistence.

What this lesson does NOT cover

Deliberately out of scope:

Persistent saga state across crashes (production saga frameworks)
Idempotent undo operations (so retrying an undo is safe — same primitive as elsewhere)
Distributed coordination (multiple workers running steps)

Those are framework territory. The application-layer pattern — log what you did, undo in reverse — is what carries through.

Multi-step rollback — best-effort transaction emulation

Why this matters

The pattern

Building the undo

Irreversible actions

Logging the rollback

Saga pattern (production-grade)

What this lesson does NOT cover

Multi-step rollback — best-effort transaction emulation

Why this matters

The pattern

Building the undo

Irreversible actions

Logging the rollback

Saga pattern (production-grade)

What this lesson does NOT cover

Multi-step rollback — best-effort transaction emulation

Why this matters

The pattern

Building the undo

Irreversible actions

Logging the rollback

Saga pattern (production-grade)

What this lesson does NOT cover

Sign up to practice

Multi-step rollback — best-effort transaction emulation

Why this matters

The pattern

Building the undo

Irreversible actions

Logging the rollback

Saga pattern (production-grade)

What this lesson does NOT cover

Sign up to practice