Software Development Engineer · 2024 – Present
Async correlation
Event-Driven Workflow Automation
Built and extended workflow automation that reacts to domain events, coordinates work across services, and keeps long-running operations auditable.
The problem
Teams depended on multi-step processes that span several services. Manual handoffs were slow, and synchronous coupling made it hard to ship changes without blocking other teams.
What I worked on
Implemented event-driven progression paths, state transition logic, and integration touchpoints between orchestration and downstream services. Wrote design docs and coordinated rollout with partner teams.
Key decisions
Used asynchronous events and callbacks instead of chaining synchronous calls. Modeled explicit lifecycle states, kept domain ownership at the service boundary, and made workflow start and task creation config-driven where it helped teams move independently.
How I handled failure
Hardened paths for duplicate events, out-of-order callbacks, and executions that had already reached a terminal state. Added observability around state transitions and failure branches so operators could trace a single record end to end.
Result
Teams could ship workflow changes incrementally without disrupting live traffic. Cross-service work became easier to reason about because progression rules and ownership were written down, not implied in ad hoc integrations.
Evidence
Event-to-workflow progression
How a domain event moves through eligibility checks, workflow start, async completion, and exit.
Teaching example (not employer-specific)
- 1
Event intake
A domain event arrives with enough context to evaluate eligibility.
- 2
Eligibility check
Rules decide whether the record should start a workflow at all.
- 3
Workflow start
The orchestrator creates or resumes a long-running execution.
- 4
Task creation
Operator-facing work is created with the state needed to act.
- 5
Async callback
An external system completes later and reports back out of band.
- 6
State transition
The workflow advances only when required inputs are present.
- 7
Exit or terminal state
Terminal paths are explicit so stale executions do not linger.
Orchestration tradeoffs
Why callbacks and a central orchestrator beat polling and point-to-point handlers for this class of problem.
Teaching example (not employer-specific)
| Option | Pros | Cons | Chosen |
|---|---|---|---|
| Callback-driven progression | Lower polling cost, faster reaction to real completions. | Requires correlation, idempotency, and timeout handling. | Yes |
| Polling downstream status | Simpler to reason about in early prototypes. | Adds load, delays, and noisy failure signals. | No |
| Central orchestrator | Clear ownership of lifecycle and audit trail. | Needs careful boundaries so domain logic does not leak in. | Yes |
| Point-to-point handlers | Fast to ship for a single integration. | Harder to evolve as more services join the flow. | No |
State invariants
Rules that had to hold true across retries, replays, and late-arriving events.
Teaching example (not employer-specific)
A transition is valid only from an allowed prior state
- Why it matters
- Prevents silent rewinds when duplicate events arrive.
- Enforcement
- Explicit state machine checks before writes.
Side effects are idempotent per correlation key
- Why it matters
- Retries and duplicate delivery should not double-create work.
- Enforcement
- Idempotency keys on task creation and downstream calls.
Terminal records cannot accept new progression
- Why it matters
- Late callbacks should fail safely instead of reviving completed work.
- Enforcement
- Guard clauses and no-op paths with structured logs.