Design Approval Workflow Engine - System Design | WinJob

Problem Statement: Approval Workflow Engine

Enterprise approval is not a CRUD form—it is a durable state machine over money, headcount, and policy. ServiceNow and Kissflow win when every procurement, expense, or policy change becomes an auditable instance with pinned definitions, parallel gates, and provable SoD.

javaOne Dark Pro

1 public final class TenantScope {
2   private final String tenantId;
3   public String partitionKey() { return tenantId; }
4 }

pythonOne Dark Pro

1 @dataclass(frozen=True)
2 class TenantScope:
3     tenant_id: str

typescriptOne Dark Pro

1 interface TenantScope {
2   tenantId: string;
3 }
4 export function partitionKey(t: TenantScope): string {
5   return t.tenantId;
6 }

Problem Statement: Approval Workflow Engine — design checkpoint (understanding)

Quote SLOs aloud: instance create P99 < 200ms, decision submit P99 < 150ms, assignee notification P95 < 30s, stuck-instance rate < 0.01%.

ServiceNow-class engines fail when approvers act on stale tokens—bind decisions to token_id + monotonic token_version.

Track submit RPS, open token depth, escalation backlog, and definition publish lag during understanding.

Note 1.1: Problem Statement: Approval Workflow Engine — guardrail: duplicate submit without idempotency key (tenant 1000, queue shard 1, policy tier 1).
Note 1.2: Problem Statement: Approval Workflow Engine — guardrail: parallel gate quorum miscount (tenant 1037, queue shard 2, policy tier 2).
Note 1.3: Problem Statement: Approval Workflow Engine — guardrail: delegation cycle in org graph (tenant 1074, queue shard 3, policy tier 3).
Note 1.4: Problem Statement: Approval Workflow Engine — guardrail: amount threshold evaluated on stale FX rate (tenant 1111, queue shard 4, policy tier 1).
Note 1.5: Problem Statement: Approval Workflow Engine — guardrail: escalation timer double-fires after leader failover (tenant 1148, queue shard 5, policy tier 2).
Note 1.6: Problem Statement: Approval Workflow Engine — guardrail: SoD violation when requester equals sole approver (tenant 1185, queue shard 6, policy tier 3).
Note 1.7: Problem Statement: Approval Workflow Engine — guardrail: definition version drift mid-flight instance (tenant 1222, queue shard 7, policy tier 1).
Note 1.8: Problem Statement: Approval Workflow Engine — guardrail: hot tenant approval queue head-of-line blocking (tenant 1259, queue shard 8, policy tier 2).
Note 1.9: Problem Statement: Approval Workflow Engine — guardrail: outbox poison after partial commit (tenant 1296, queue shard 9, policy tier 3).
Note 1.10: Problem Statement: Approval Workflow Engine — guardrail: break-glass override without immutable audit (tenant 1333, queue shard 10, policy tier 1).
Note 1.11: Problem Statement: Approval Workflow Engine — guardrail: webhook replay assigns duplicate tokens (tenant 1370, queue shard 11, policy tier 2).
Note 1.12: Problem Statement: Approval Workflow Engine — guardrail: conditional branch references retired role id (tenant 1407, queue shard 12, policy tier 3).

Why interviewers care

Approval Workflow Engine interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Approval Workflow Engine that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Highlight 1-1: Enterprise approval is not a CRUD form—it is a **durable state machine**
•Command path owns token state
•Outbox drives notify + ERP
•Definitions pinned per instance

1	public final class TenantScope {
2	private final String tenantId;
3	public String partitionKey() { return tenantId; }
4	}

1	interface TenantScope {
2	tenantId: string;
3	}
4	export function partitionKey(t: TenantScope): string {
5	return t.tenantId;
6	}

Problem Statement: Approval Workflow Engine

Problem Statement: Approval Workflow Engine — design checkpoint (understanding)

Why interviewers care

Interview checkpoint

Key Highlights

Section Rescue Kit