Ride Sharing Service - Learning Module

Loading content...

0/246

Patterns Applied: Strategy, Observer, State

Patterns as Architectural Glue

Throughout our ride-sharing design, we've applied design patterns at critical points. Now we consolidate this understanding, showing how Strategy, Observer, State, and Factory patterns work together to create a system that is flexible, maintainable, and extensible.

Why patterns matter for complex systems:

Patterns aren't decorative—they solve specific structural problems. In ride-sharing, variability in matching algorithms, pricing models, state handling, and notifications would create unmanageable complexity without patterns. Each pattern isolates a dimension of variability, allowing that aspect to change independently.

What You Will Learn

By the end of this page, you will see how Strategy pattern enables algorithm swapping (matching, pricing), Observer pattern decouples event notification, State pattern manages trip lifecycle, and Factory pattern centralizes object creation. You'll understand when and why each pattern is applied.

Strategy Pattern: Algorithm Swapping

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. It lets the algorithm vary independently from clients that use it.

Strategy applications in ride-sharing:

MatchingStrategy: Different algorithms for ranking drivers (nearest, best ETA, weighted score, fair distribution)
PricingStrategy: Different pricing models for vehicle types (standard, premium, pool)
AllocationStrategy: How to assign drivers to requests (first available, optimal batch)
SurgeCalculationStrategy: Different surge formulas for different markets

StrategyPatternUsage.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// Strategy interface for matching
interface MatchingStrategy {
    rankDrivers(candidates: DriverWithDistance[], request: RideRequest): DriverWithDistance[];
}
 
// Concrete strategies
class NearestDriverStrategy implements MatchingStrategy { /* ... */ }
class WeightedScoreStrategy implements MatchingStrategy { /* ... */ }
class FairDistributionStrategy implements MatchingStrategy { /* ... */ }
 
// Context that uses the strategy
class MatchingEngine {
    private strategy: MatchingStrategy;
 
    constructor(strategy: MatchingStrategy) {
        this.strategy = strategy;
    }
 
    // Strategy can be changed at runtime
    setStrategy(strategy: MatchingStrategy): void {
        this.strategy = strategy;
    }
 
    async findMatch(request: RideRequest): Promise<MatchResult> {
        const candidates = await this.findCandidates(request);
        // Delegate ranking to strategy
        const ranked = this.strategy.rankDrivers(candidates, request);
        return this.processRankedCandidates(ranked);
    }
}
 
// Usage: swap strategies based on conditions
function selectMatchingStrategy(context: MatchingContext): MatchingStrategy {
    if (context.isPeakHours) {
        return new NearestDriverStrategy();  // Speed matters most
    } else if (context.isLowSupply) {
        return new FairDistributionStrategy();  // Keep all drivers engaged
    } else {
        return new WeightedScoreStrategy();  // Balance all factors
    }
}

Strategy Selection

Notice how策略 selection can be dynamic—based on time of day, supply conditions, or A/B test cohorts. This enables experimentation without code changes to the matching engine itself.

Observer Pattern: Event Notification

The Observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically.

Observer applications in ride-sharing:

Trip Events: Notify rider and driver when trip state changes
Driver Location: Broadcast location updates to tracking systems
Surge Updates: Notify pricing system when surge zones change
Rating Events: Update driver/rider scores when ratings are submitted

ObserverPattern.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
// Event types for the trip lifecycle
interface TripEvent {
    tripId: string;
    eventType: TripEventType;
    timestamp: Date;
    data: Record<string, unknown>;
}
 
enum TripEventType {
    DRIVER_ASSIGNED = 'DRIVER_ASSIGNED',
    DRIVER_ARRIVED = 'DRIVER_ARRIVED',
    TRIP_STARTED = 'TRIP_STARTED',
    TRIP_COMPLETED = 'TRIP_COMPLETED',
    TRIP_CANCELLED = 'TRIP_CANCELLED',
    LOCATION_UPDATED = 'LOCATION_UPDATED',
}
 
// Observer interface
interface TripEventObserver {
    onTripEvent(event: TripEvent): void;
}
 
// Subject (Observable)
class TripEventPublisher {
    private observers: TripEventObserver[] = [];
 
    subscribe(observer: TripEventObserver): void {
        this.observers.push(observer);
    }
 
    unsubscribe(observer: TripEventObserver): void {
        this.observers = this.observers.filter(o => o !== observer);
    }
 
    publish(event: TripEvent): void {
        for (const observer of this.observers) {
            observer.onTripEvent(event);
        }
    }
}
 
// Concrete observers
class RiderNotificationObserver implements TripEventObserver {
    private notificationService: NotificationService;
 
    onTripEvent(event: TripEvent): void {
        switch (event.eventType) {
            case TripEventType.DRIVER_ASSIGNED:
                this.notificationService.notifyRider(
                    event.data.riderId as string,
                    'Your driver is on the way!',
                    event.data
                );
                break;
            case TripEventType.DRIVER_ARRIVED:
                this.notificationService.notifyRider(
                    event.data.riderId as string,
                    'Your driver has arrived!',
                    event.data
                );
                break;
            // ... other events
        }
    }
}
 
class DriverNotificationObserver implements TripEventObserver {
    onTripEvent(event: TripEvent): void {
        // Notify driver of relevant events
    }
}
 
class AnalyticsObserver implements TripEventObserver {
    onTripEvent(event: TripEvent): void {
        // Log event for analytics pipeline
        console.log(`Analytics: ${event.eventType} at ${event.timestamp}`);
    }
}
 
class AuditLogObserver implements TripEventObserver {
    onTripEvent(event: TripEvent): void {
        // Persist event for compliance and debugging
    }
}
 
// Usage: register observers at startup
const tripEventPublisher = new TripEventPublisher();
tripEventPublisher.subscribe(new RiderNotificationObserver(notificationService));
tripEventPublisher.subscribe(new DriverNotificationObserver(notificationService));
tripEventPublisher.subscribe(new AnalyticsObserver());
tripEventPublisher.subscribe(new AuditLogObserver());

Decoupling Through Observer

The Trip entity doesn't know about notifications, analytics, or auditing. It just publishes events. New concerns (e.g., fraud detection, real-time dashboards) can be added as new observers without modifying Trip or existing observers. This is the Open/Closed Principle in action.

State Pattern: Lifecycle Management

The State pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

State pattern in ride-sharing:

While we implemented the trip state machine using enums and explicit transitions, a more sophisticated approach uses the State pattern where each state is a class with allowed behaviors.

Benefits:

State-specific logic is encapsulated in state classes
Adding new states doesn't modify existing state logic
Transitions and allowed actions are explicit per state

StatePattern.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
// State interface
interface TripState {
    getName(): string;
    
    // Actions with default implementations throwing "not allowed"
    onDriverAssigned(trip: Trip, driver: Driver): TripState;
    onDriverArrived(trip: Trip): TripState;
    onTripStarted(trip: Trip): TripState;
    onTripCompleted(trip: Trip): TripState;
    onCancelledByRider(trip: Trip): TripState;
    onCancelledByDriver(trip: Trip): TripState;
}
 
// Abstract base with default "not allowed" implementations
abstract class BaseTripState implements TripState {
    abstract getName(): string;
 
    onDriverAssigned(trip: Trip, driver: Driver): TripState {
        throw new Error(`Cannot assign driver in ${this.getName()} state`);
    }
    onDriverArrived(trip: Trip): TripState {
        throw new Error(`Driver cannot arrive in ${this.getName()} state`);
    }
    onTripStarted(trip: Trip): TripState {
        throw new Error(`Cannot start trip in ${this.getName()} state`);
    }
    onTripCompleted(trip: Trip): TripState {
        throw new Error(`Cannot complete trip in ${this.getName()} state`);
    }
    onCancelledByRider(trip: Trip): TripState {
        throw new Error(`Cannot cancel in ${this.getName()} state`);
    }
    onCancelledByDriver(trip: Trip): TripState {
        throw new Error(`Cannot cancel in ${this.getName()} state`);
    }
}
 
// Concrete states
class MatchingState extends BaseTripState {
    getName(): string { return 'MATCHING'; }
 
    onDriverAssigned(trip: Trip, driver: Driver): TripState {
        trip.setDriver(driver);
        trip.setMatchedAt(new Date());
        return new DriverAssignedState();
    }
 
    onCancelledByRider(trip: Trip): TripState {
        trip.setCancelledAt(new Date());
        return new CancelledByRiderState();
    }
}
 
class DriverAssignedState extends BaseTripState {
    getName(): string { return 'DRIVER_ASSIGNED'; }
 
    onDriverArrived(trip: Trip): TripState {
        trip.setDriverArrivedAt(new Date());
        return new DriverArrivedState();
    }
 
    onCancelledByRider(trip: Trip): TripState {
        // May trigger cancellation fee
        trip.setCancelledAt(new Date());
        return new CancelledByRiderState();
    }
 
    onCancelledByDriver(trip: Trip): TripState {
        trip.setCancelledAt(new Date());
        return new CancelledByDriverState();
    }
}
 
class DriverArrivedState extends BaseTripState {
    getName(): string { return 'DRIVER_ARRIVED'; }
 
    onTripStarted(trip: Trip): TripState {
        trip.setTripStartedAt(new Date());
        return new TripInProgressState();
    }
 
    onCancelledByRider(trip: Trip): TripState {
        // Definitely charges cancellation fee
        trip.setCancelledAt(new Date());
        return new CancelledByRiderState();
    }
}
 
class TripInProgressState extends BaseTripState {
    getName(): string { return 'TRIP_IN_PROGRESS'; }
 
    onTripCompleted(trip: Trip): TripState {
        trip.setTripCompletedAt(new Date());
        return new TripCompletedState();
    }
}
 
class TripCompletedState extends BaseTripState {
    getName(): string { return 'TRIP_COMPLETED'; }
    // Terminal state - no transitions allowed
}
 
// Trip context using state pattern
class Trip {
    private state: TripState;
    // ... other fields
 
    constructor() {
        this.state = new RequestedState();
    }
 
    assignDriver(driver: Driver): void {
        this.state = this.state.onDriverAssigned(this, driver);
    }
 
    driverArrived(): void {
        this.state = this.state.onDriverArrived(this);
    }
 
    startTrip(): void {
        this.state = this.state.onTripStarted(this);
    }
 
    completeTrip(): void {
        this.state = this.state.onTripCompleted(this);
    }
 
    getStateName(): string {
        return this.state.getName();
    }
}

Factory Pattern: Object Creation

The Factory pattern provides an interface for creating objects without specifying their exact classes. It centralizes creation logic and can return different implementations based on parameters.

Factory applications in ride-sharing:

TripFactory: Create Trip instances with proper initialization
FareFactory: Create Fare objects from calculation results
NotificationFactory: Create appropriate notification types
StrategyFactory: Return appropriate strategy based on context

FactoryPattern.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
class TripFactory {
    private pricingStrategyFactory: PricingStrategyFactory;
    private fareCalculator: FareCalculator;
    private idGenerator: IdGenerator;
 
    createTrip(
        rider: Rider,
        pickupLocation: Location,
        destination: Location,
        vehicleType: VehicleType
    ): Trip {
        // Generate unique ID
        const tripId = this.idGenerator.generate('trip');
 
        // Get appropriate pricing strategy
        const pricingStrategy = this.pricingStrategyFactory.getStrategy(vehicleType);
 
        // Calculate estimated fare
        const estimatedDistance = pickupLocation.distanceTo(destination);
        const estimatedDuration = this.estimateDuration(estimatedDistance);
        const surgeMultiplier = this.getSurgeMultiplier(pickupLocation);
 
        const estimatedFare = pricingStrategy.calculateFare({
            distanceKm: estimatedDistance,
            durationMinutes: estimatedDuration,
            vehicleType,
            pickupLocation,
            isEstimate: true,
        }, surgeMultiplier);
 
        // Create and configure trip
        const trip = new Trip(
            tripId,
            rider,
            pickupLocation,
            destination,
            estimatedFare
        );
 
        // Additional initialization
        trip.setVehicleType(vehicleType);
        trip.setSurgeMultiplier(surgeMultiplier);
 
        return trip;
    }
 
    private estimateDuration(distanceKm: number): number {
        // Rough estimate: 25 km/h average city speed
        return (distanceKm / 25) * 60;
    }
 
    private getSurgeMultiplier(location: Location): number {
        // Would query SurgePricingService
        return 1.0;
    }
}
 
// Strategy factory - returns appropriate strategy
class MatchingStrategyFactory {
    createStrategy(context: MatchingContext): MatchingStrategy {
        if (context.rideType === 'POOL') {
            return new PoolMatchingStrategy();
        } else if (context.isPeakHours) {
            return new NearestDriverStrategy();
        } else {
            return new WeightedScoreStrategy();
        }
    }
}

Patterns Working Together

The power of patterns emerges when they work together. Here's how our patterns collaborate:

Request → Trip flow:

Factory creates Trip with estimated fare (using pricing Strategy)
MatchingEngine uses matching Strategy to rank drivers
Driver accepts → Trip State transitions to DRIVER_ASSIGNED
State change publishes event via Observer pattern
Observers notify rider, log analytics, update dashboards

This separation means:

Changing matching algorithm doesn't affect state management
Adding new notifications doesn't modify trip logic
New pricing tiers require only a new strategy implementation
State machine evolution doesn't touch observers

Pattern Responsibility Summary
Pattern	Responsibility	Examples in System
Strategy	Encapsulate interchangeable algorithms	MatchingStrategy, PricingStrategy, SurgeStrategy
Observer	Decouple event producers from consumers	TripEventPublisher → Notifications, Analytics, Audit
State	Manage object lifecycle with state-specific behavior	TripState classes managing transitions
Factory	Centralize and encapsulate object creation	TripFactory, StrategyFactory, FareFactory

Interview Insight

When explaining your design, explicitly name patterns and their purpose: 'I'm using Strategy for pricing because different vehicle types have different rate structures, and I want to add new tiers without modifying existing code.' This demonstrates pattern fluency and SOLID understanding.

Patterns Summary

Key Takeaways

•Strategy pattern enables algorithm flexibility — Matching and pricing strategies can be swapped based on context without changing core logic.
•Observer pattern decouples event handling — Trip publishes events; notifications, analytics, and audit log independently.
•State pattern manages lifecycle complexity — Each trip state encapsulates its allowed transitions and behaviors.
•Factory pattern centralizes creation — Trip creation includes fare estimation, ID generation, and proper initialization.
•Patterns work together — Factory creates configured objects, State manages lifecycle, Strategy handles variations, Observer broadcasts changes.

What's next:

In our final page, we'll consolidate everything into a complete design walkthrough—showing the full system architecture with class diagrams, sequence diagrams, and interview presentation guidance.

Page Complete

You now understand how Strategy, Observer, State, and Factory patterns work together in the ride-sharing system. Each pattern addresses a specific design challenge, and together they create a flexible, maintainable architecture. Next, we present the complete integrated design.