Skip to content
Zeni Study
Share
Explore

DAY 5 — Workflow Design & Config-Driven Systems (SDE-2+)

Awesome — Day 5 is very close to real backend services you’d build at work. Interviewers use these problems to see whether you can model workflows, partial failures, and configuration-driven behavior, not just write classes.
Today tests:
State machines
Orchestration logic
Deterministic behavior
Failure awareness
⁠

🟣 DAY 5 — Workflow Design & Config-Driven Systems (SDE-2+)

⁠

Concepts Introduced Today (Interview-Focused)

1️⃣ Explicit Workflow / State Machine

Complex systems are pipelines, not linear code.
Bad:
pay();
ship();
Good:
CREATED → PAID → FULFILLED
↓
FAILED
Interviewers expect you to encode states, not imply them.
⁠

2️⃣ Determinism

Feature flags & rollouts must:
Give the same answer for the same user
Not fluctuate randomly
Random without seed = ❌
⁠

✅ Problem 1: Order Processing Pipeline

⁠

📌 Problem Statement

Design an order processing system that handles:
Order creation
Payment
Fulfillment
Failure handling
⁠

Order States

CREATED
PAID
PAYMENT_FAILED
FULFILLED
⁠

Functional Requirements

createOrder(orderId, amount)
processPayment(orderId) → may fail
fulfillOrder(orderId) → only if PAID
getOrderState(orderId)
⁠

Rules

Payment failure moves order to PAYMENT_FAILED
Fulfillment only allowed from PAID
Once FULFILLED, state is terminal
⁠

Example

createOrder("o1", 100)
processPayment("o1") → success
fulfillOrder("o1") → success
state = FULFILLED
⁠

🧩 Java Interfaces (DO NOT MODIFY)

public enum OrderState {
CREATED,
PAID,
PAYMENT_FAILED,
FULFILLED
}
public interface OrderService {
void createOrder(String orderId, long amount);
boolean processPayment(String orderId);
boolean fulfillOrder(String orderId);
OrderState getOrderState(String orderId);
}
⁠

🧪 Driver Code (Auto Tests + Edge Cases)

public class OrderServiceTest {

public static void main(String[] args) {
OrderService service = new InMemoryOrderService();

service.createOrder("o1", 100);
assert service.getOrderState("o1") == OrderState.CREATED;

boolean paid = service.processPayment("o1");
if (paid) {
assert service.getOrderState("o1") == OrderState.PAID;
assert service.fulfillOrder("o1");
assert service.getOrderState("o1") == OrderState.FULFILLED;
} else {
assert service.getOrderState("o1") == OrderState.PAYMENT_FAILED;
assert !service.fulfillOrder("o1");
}

// Idempotency
assert !service.processPayment("o1");
assert !service.fulfillOrder("o1");

System.out.println("✅ OrderService tests passed");
}
}
⁠

🎯 What Interviewer Evaluates

State validation
Correct transitions
No illegal operations
Clear domain modeling
⁠

✅ Problem 2: Feature Flag System (Deterministic Rollout)

⁠

📌 Problem Statement

Design a feature flag system supporting:
Enable / disable features
Percentage rollout
Deterministic per-user decision
⁠

Functional Requirements

isEnabled(featureName, userId)
Percentage rollout (0–100)
Same user always gets same result
⁠

Rules

If feature disabled → always false
If rollout = 30% → approx 30% users enabled
Must be deterministic (hash-based)
⁠

Example

Feature: NEW_UI
Enabled: true
Rollout: 50%

userA → enabled
userA → enabled (always)
userB → disabled
⁠

🧩 Java Interfaces (DO NOT MODIFY)

public interface FeatureFlagService {
void createFeature(String featureName, boolean enabled, int rolloutPercentage);
boolean isEnabled(String featureName, String userId);
}
⁠

🧪 Driver Code (Auto Tests + Edge Cases)

public class FeatureFlagTest {

public static void main(String[] args) {
FeatureFlagService service = new InMemoryFeatureFlagService();

service.createFeature("NEW_UI", true, 50);

boolean u1 = service.isEnabled("NEW_UI", "user1");
boolean u2 = service.isEnabled("NEW_UI", "user1");
assert u1 == u2; // determinism
Gallery
 
Want to print your doc?
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.