Jaeyoung Heo

Software Engineer — Backend Systems & Domain Architecture

I turn tangled domains into explicit, verifiable structure. My work is about modeling real constraints and decisions as executable systems, then changing those systems without losing their meaning.

Backend systems · Domain architecture · Runtime & orchestration · Performance & observability

  1. Build structures other engineers can extend.

    Complex rules should not live in one person's head. I separate responsibilities and boundaries so new requirements do not destabilize the existing flow.

  2. Make execution order visible.

    I prefer schedulers, DAGs, and queues that can be read and verified over implicit callback chains. The same input should produce the same result.

  3. Treat correctness as a design property.

    I establish trial, commit, and rollback boundaries early. Failed attempts should be unable to leave partial state behind.

  4. Preserve domain meaning in types and models.

    I lift hardcoded branches into formal structure. Decision context and lineage should survive all the way down to execution.

  5. Observe first, measure, then change.

    Profiles and traces decide where I optimize. If the evidence cannot justify the complexity, I roll the change back.

Procedural calculation flow → 16-stage DAG engine

Before

Calculation rules and execution order were tangled across procedures, making individual stages hard to verify or replace safely.

After

I built a 16-stage dependency graph and a new execution module, then migrated the full workflow behind continuous result comparison.

  • Designed and implemented the new 123-file V2 module from the ground up
  • Regression-checked 1,092 demands; all 964 comparable results matched the existing engine exactly
  • Combined snapshot restore, stage execution, result comparison, and rollback boundaries so the migration itself stayed verifiable

12 event sources → one deterministic scheduler

Before

Each event source calculated its next time independently, while conditionals and side effects obscured the system-wide order.

After

I moved scheduling into one heap and channel metadata, then made tie-breaking and time monotonicity explicit contracts.

  • Defined same-time priority, stale-entry cleanup, and rescheduling rules in one place
  • Preserved behavior and test parity while reducing the implementation by roughly 940 net lines
  • Separated scheduling from domain behavior so new event sources fit the same boundary

God object → 15 components and an explicit Facade

Before

A 3,800-line class held 114 attributes and several concerns, while proxies hid who actually owned each piece of state.

After

I moved state into 15 components and exposed it through an explicit Facade, making ownership and change paths visible.

  • Migrated in stages: reclaim state ownership, move call sites, then remove the proxies
  • Implemented and evaluated ECS, then chose the simpler Facade boundary when ECS made lookups too indirect
  • Separated extension points so new features no longer need direct access to core internals

Multi-resource reservation → trial, commit, rollback

Before

If one resource failed halfway through a route, earlier mutations could survive and corrupt the next calculation.

After

I made the whole route provisional, committed it atomically, and restored every related state on failure.

  • Kept resource-specific constraints separate while committing the route through one transaction boundary
  • Tracked state by chain so rollback order remains correct through nested routes and partial failures
  • This contract became part of the foundation for the V2 engine's 964/964 result parity

A traceable engine and evidence-led performance work

Before

Logging was expensive on hot paths, but removing it made unexpected decisions nearly impossible to explain.

After

I standardized structured traces across the engine and made them disappear at compile time in optimized production runs.

  • Used Python's __debug__ gating to separate development traceability from production hot-path cost
  • Changed data structures and repeated operations only after profiling showed where time was going
  • Rolled back asynchronous logging and database parallelism experiments when their gains did not justify their complexity

Recent work and research

Deterministic simulation engine in Rust Personal R&D · v0.1.0

A private project that separates policy from physical execution and lowers validated components into a reusable atom graph.

  • Integer time and a total event order make two runs of the same input byte-identical at the event-log level
  • 540 tests and 200 generated networks check determinism, quantity conservation, and Little's Law
  • The prepared branch plan is complete; runtime lowering is still next, so I do not present it as a finished product

Kubernetes execution boundary and image supply chain Phase 1 merged

I designed and cluster-tested a boundary that moves long calculations out of the web process and into an isolated Kubernetes Job per run.

  • Kept the server as a control plane and separated execution state from artifact lifecycle
  • A real k3s spike exposed a 12-hour pull-secret expiry that would have broken long-lived operation, prompting a credential-boundary redesign
  • Added immutable tags and OCI labels and reduced the image from 708MB to 357MB; the follow-up phase remains in progress

Domain IR and execution semantics Experimental

Research into expressing complex calculation rules as a smaller language of tokens, actions, and schedulers.

  • Kept the experiment separate from the production V2 path so failed ideas cannot destabilize the current system
  • Defines state transitions and verification boundaries before optimizing stage output
  • Leaves incomplete semantics visible as blockers instead of silently approximating them

Mentoring and writing

Python deep-dive series — A series written for junior-engineer onboarding. It explains why Python's object model, containers, generators, and descriptors behave the way they do rather than stopping at syntax.

Long-form notes on compilers, Linux, computer architecture, and Python internals. Read the tech blog →

Contact

I am always glad to talk about backend systems, domain architecture, runtimes, performance, and observability.

GitHub