Skip to content
Zeni Study
  • Pages
    • Learn Python In 7 Days
      • Day 1 : Variable + if/else
      • Day 2: Loops
      • Day 3 : Array + String
      • Day 4 — Functions
      • Day 5 — Dictionaries - Hashmap
      • Day 6 — Files & Errors
      • Day 7 — Mini Project & Programmer Thinking
    • Machine Coding:
      • Day 1 — Bank account + Wallet :
      • Day 2 : RateLimiter + seat booking
      • Day 3 : Library Management + Classroom Attendance System
      • Day 4 : Bank account and notification system.
      • Day 5 : Key-value and payment processor.
      • Day 6 : Discount engine + Seat booking( in depth)
      • Day 7: Parking lot System :
    • Machine coding extended:
      • Day 7.5 — Parking Lot (Constraint-Heavy Variant)
      • Day 8 : Order + Payment System
      • Day 8 — Extension Round (Mid-Interview Change)
      • Day 9 — Ticket Booking with Expiry (Simulated Time)
      • Day 9 — Extension Round (Seat Lock Ownership + Forced Unlock)
    • SQL + DB Thinking course
      • Day 1 — Tables, Rows & Thinking in Data
      • Day 2 — Relationships & Foreign Keys (Thinking in Connections)
      • Day 3 — Filtering, Aggregation & Answering Data Questions
      • Day 4 — JOINs (Combining Tables the Right Way)
      • Day 5 — Subqueries, EXISTS & NOT EXISTS (Thinking in Layers)
      • Day 6 — Indexes, Constraints & How Databases Think
      • Day 7 — Full SQL Interview Simulation (SDE-1 Ready)
      • Extended Day 1 — Core Business Systems (Deep Practice)
      • Extended Day 2 — Booking & Platform Systems (High-Depth Practice)
      • Extended Day 3 — Content & Learning Platforms (Capstone Practice)
    • LLD: Java
      • DAY 1 — Core Foundations (SDE-2 Level)
      • DAY 2 — State, Time & Domain Correctness
      • DAY 3 — Extensibility & Failure Handling (SDE-2 Core Signal)
      • DAY 4 — Concurrency, Scheduling & Consistency (SDE-2 Critical)
      • icon picker
        DAY 5 — Workflow Design & Config-Driven Systems (SDE-2+)
      • DAY 6 — Eventing & Usage-Based Systems (Advanced SDE-2)
      • DAY 7 — Interview Simulation (Hard, Production-Grade)
      • Hidden Edge Cases Interviewers Expect (Day-wise)
      • Detailed Testing file:
    • Assignment:
      • If else Practice Set
Zeni Study
/
/
DAY 5 — Workflow Design & Config-Driven Systems (SDE-2+)
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

service.createFeature("BETA", false, 100);
assert !service.isEnabled("BETA", "user2");

service.createFeature("ALL_ON", true, 100);
assert service.isEnabled("ALL_ON", "anyUser");

service.createFeature("NONE", true, 0);
assert !service.isEnabled("NONE", "anyUser");

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

🎯 What Interviewer Evaluates

Deterministic logic
Boundary handling (0%, 100%)
Clean configuration modeling
No randomness per call
⁠

🧠 Day 5 Takeaways

After today, you should:
Model real backend workflows
Encode state transitions explicitly
Build config-driven logic
Think in terms of systems, not functions
This is very strong SDE-2 signal and borderline SDE-3 readiness.
⁠
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.