300 likes | 382 Views
Changing Car’s Engine While on a Race. Go-Food. Bergas Bimo Branarto Software Engineer. Covering:. Go-Jek: multiple moving parts across system, high speed Initial Go-Food architecture Splitting Go-Food OMS from monolith system: Why, How, Result Lesson learnt. Go-Jek: multiple moving parts.
E N D
Changing Car’s Engine While on a Race Go-Food Bergas Bimo Branarto Software Engineer
Covering: • Go-Jek: multiple moving parts across system, high speed • Initial Go-Food architecture • Splitting Go-Food OMS from monolith system: Why, How, Result • Lesson learnt
Go-Jek: multiple moving parts • Lots of new products and features across products • Lots of new services: on-going monolith migrations and/or scaling other services
Why did we need to change Go-Food engine? • Scalability and reliability • New feature development time • Enabling easier parallel development on 4 streams: resto, discovery, discounting, international
pricing platform pricing platform driver platform driver platform pricing platform (part of) StanMarsh Go-Food Order Flow Components & Dependencies - Initial allocation gopay-balance gopay-balance gopay-balance gopay-balance gopay-voucher driver platform gopay-voucher gopay-voucher gopay-voucher Pre-Order Order State Flow Order(s) View Price Estimation Create Order Order Pickup Order Cancellation Order Completion Order History Order Detail notification gopay-balance notification goresto termination service termination service gopay-voucher notification order history driver platform gofood cms goresto Supported Payment Types: Cash, GoPay (+Partial Payment), Vouchers Supported Merchant Type: Non-partner, partner-non goresto, partner-goresto
pricing platform driver platform pricing platform pricing platform driver platform Go-Food Order Flow Components & Dependencies allocation gopay-balance gopay-balance gopay-balance gopay-balance gopay-voucher driver platform gopay-voucher gopay-voucher gopay-voucher • Many dependencies • Some dependencies are also in progress of rewrites: API contracts are moving targets • Tricky implementation especially in GoPay integration: different DC: network unreliability is high notification notification gopay-balance goresto termination service termination service notification gopay-voucher order history driver platform gofood cms goresto Supported Payment Types: Cash, GoPay (+Partial Payment), Vouchers Supported Merchant Type: Non-partner, partner-non goresto, partner-goresto
(part of) StanMarsh New System Go-Food OMS Rewrite Strategy Pre-Order Order State Flow Order(s) View Price Estimation Create Order Order Pickup Order Cancellation Order Completion Order History Order Detail Pre-Order Order State Flow Order(s) View Price Estimation Create Order Order Pickup Order Cancellation Order Completion Order History Order Detail • Constraints • Fast iteration • Avoid changes in StanMarsh (as much as we can) • 0 dependency to StanMarsh DB • Reusable components (gojek platform) • 0 downtime and revertible For first iteration, we picked a component which (relatively) independent to the others -> Price Estimation
staggered rollout by customer id & Traffic percentage Price Estimation - iteration #1 Goal: 0 RPM on stanmarsh’s go-food price estimation API gofood pricing as source of truth for Go-Food price calculations redis To avoid downtime and make it revertible, we did staggered rollout stanmarsh pricing platform switch by product gopay-balance gate price estimation gopay-voucher consumer gofood pricing
Pre-Order New System (part of) StanMarsh GoFood Pricing Price Estimation Pre-Order Order State Flow Order(s) View Go-Food OMS Rewrite Strategy - iteration #1 final Create Order Price Estimation Order Pickup Order Cancellation Order Completion Order History Order Detail Order State Flow Order(s) View To keep ourself focus and easier to maintain data consistency, we migrated 1 order state flow in one go. Create Order Order Pickup Order Cancellation Order Completion Order History Order Detail HOW TO MANAGE SO MANY DEPENDENCIES WHILE STILL ACHIEVING FAST ITERATION?
(part of) StanMarsh gopay-balance gopay-voucher goresto gopay-voucher gopay-balance gopay-voucher gopay-balance Go-Food OMS Rewrite Strategy - iteration #2 preparing goresto gopay-voucher gopay-balance Order State Flow Order(s) View Create Order Order Pickup Order Cancellation Order Completion Order History Order Detail pricing platform pricing platform driver platform driver platform order history driver platform allocation driver platform notification notification notification termination service termination service To iterate fast, we removed some dependencies Flow with minimum dependencies is…… Cash - NonVoucher - NonGoResto Order
GF-<number> stanmarsh gofood oms cash-voucher gopay-nonvoucher gopay-voucher Goresto cash/gopay/voucher Create Order - iteration #2 preparing Goal: 0 RPM on stanmarsh’s go-food cash non-voucher non-goresto order creation 0 records of Go-Food cash non-voucher non-goresto order in stanmarsh DB Create structure of the new Go-Food order management system staggered rollout by customer id & Traffic percentage To avoid downtime and make it revertible, we did staggered rollout F-<number> switch by product gofood pricing gate create order consumer IT’S USING A DIFFERENT DB, HOW SHALL THE USERS SEE ORDER DETAILS?
switch by order number prefix gofood order detail switch by order number prefix Order Detail - iteration #2 Goal: 0 RPM on stanmarsh’s go-food order detail APIs New Gofood Order Detail as source of truth for all gofood orders details gofood oms cust care driver care merchant care stanmarsh Order detail gate driver platform Order detail consumer driver GF-* F-* Make use of new order number pattern initial: <numbers> gofood-stanmarsh: GF-<numbers> gofood-final: F-<numbers>
Order(s) View GoFood Pricing (part of) StanMarsh GoFood Order Detail Pre-Order Go-Food OMS Rewrite - iteration #2 final Price Estimation Order Detail Order State Flow Order(s) View Create Order Order Pickup Order Cancellation Order Completion Order Detail Order History LET’S CONTINUE TO CASH NON-VOUCHER NON-GORESTO ORDER FLOW! ITERATION #3
(3) POST price-calculation (12.b) customer should be able to see his order detail (6.a) driver accepts order (2) POST create-order (4.a) POST create-bid (7) callback driver found (5) notif to driver (3.b) get delivery price kafka stream (4.b) response order created (1) create order (11) consume (9.a) POST cust-notif (6.b) poll active order detail (8) mark driver active order (9.b) notif driver found Create Order Cash NonVoucher Non-Goresto - iteration #3 • (10) push • event These are (relatively) new services, we migrated to these new services as part of this iteration, keeping the flow in stanmarsh to use the old one Goal: Create structure of the new Go-Food order management system (12.a) customer should be able to see his order in active order list consumer driver pricing platform gofood pricing gofood order detail gate allocation gofood oms notification driver platform order history
Get orders which created in new Go-Food OMS Order History - iteration #3 Goal: 0 RPM on stanmarsh’s go-food order history APIs Use history service as source of truth for customer order history order history consumer stanmarsh Get orders which created in StanMarsh (existing) switch by product gate order history
switch by order number prefix kafka stream price recalculation gate Order Pickup Cash NonVoucher NonGoresto - iteration #3 Goal: 0 RPM on stanmarsh’s go-food order pickup APIs consumer driver pricing platform gofood pricing notification gofood oms gofood order detail order history
switch by order number prefix clear driver active order driver statistic (for performance) kafka stream get order detail gate Order Cancellation Cash NonVoucher Non-Goresto - iteration #3 Goal: 0 RPM on stanmarsh’s go-food order cancellation APIs OMS as order state manager and orchestrator driver care consumer driver consumer driver termination service driver platform get order detail notification gofood oms gofood order detail order history
switch by order number prefix kafka stream gate Order Completion Cash NonVoucher Non-Goresto - iteration #3 Goal: 0 RPM on stanmarsh’s go-food order completion APIs OMS as order state manager and orchestrator consumer clear driver active order driver statistic (for performance) driver rewards termination service driver platform notification gofood oms driver gofood order detail driver care order history
Go-Food OMS GoFood Pricing (part of) StanMarsh Order History Pre-Order Order State Flow Order History Go-Food OMS Rewrite - iteration #3 final Create Order Price Estimation Order Pickup Order Cancellation Order Completion cash non-voucher non-goresto flow is covered Order State Flow Orders View Create Order Order Pickup Order Cancellation Order Completion Order History Order(s) View GoFood Order Detail Order Detail NEXT: GOPAY VOUCHER NON-GORESTO ORDER FLOW! ITERATION #4
notif to driver get voucher detail create-bid get customer balance Create Order GoPay Voucher NonGoresto - iteration #4 driver accepts order reserve voucher reserve balance callback driver found gopay-balance gopay-voucher mark driver active order poll active order detail notif driver found pricing platform gofood pricing gate allocation gofood oms create order driver consumer notification driver platform kafka stream order history
switch by order number prefix kafka stream gate Order Pickup GoPay Voucher NonGoresto - iteration #4 re-reservation re-reservation consumer driver gopay-balance gopay-voucher pricing platform gofood pricing notification gofood oms gofood order detail order history
kafka stream get order detail cancel reservation Order Cancellation GoPay Voucher Non-Goresto - iteration #4 driver care consumer driver consumer driver cancel reservation get order detail gopay-balance termination service driver platform gate notification gofood oms gopay-voucher gofood order detail order history
kafka stream customer + driver transaction voucher redemption Order Completion GoPay Voucher Non-Goresto - iteration #4 driver care consumer driver gopay-balance gopay-voucher get order detail termination service driver platform gate notification gofood oms gofood order detail order history
Go-Food OMS GoFood Pricing (part of) StanMarsh Order History Pre-Order Order State Flow Order History Go-Food OMS Rewrite - iteration #4 final Create Order Price Estimation Order Pickup Order Cancellation Order Completion cash non-voucher non-goresto flow is covered Order State Flow Orders View Create Order Order Pickup Order Cancellation Order Completion Order History Order(s) View GoFood Order Detail Order Detail gopay voucher non-goresto flow is covered NEXT: GORESTO ORDER FLOW! ITERATION #5
switch by order number prefix consume kafka stream Pin validation gate Order Pickup GoResto - iteration #5 driver + merchant transaction consumer driver gopay-balance gopay-voucher pricing platform gofood pricing notification gofood oms goresto gofood order detail order history
gopay-balance gopay-voucher kafka stream customer + driver transaction voucher redemption Order Completion Goresto - iteration #5 driver care consumer driver termination service driver platform transaction customer: full price driver: only delivery price get order detail notification gate gofood oms gofood order detail order history
Go-Food OMS GoFood Pricing (part of) StanMarsh Order History Pre-Order Order State Flow Order State Flow Orders View Order History Go-Food OMS Rewrite - iteration #5 final Create Order Price Estimation Order Pickup Create Order Order Cancellation Order Pickup Order Completion Order Cancellation Order Completion Order History cash non-voucher non-goresto flow is covered MISSION ACCOMPLISHED! Order(s) View GoFood Order Detail Order Detail gopay voucher non-goresto flow is covered goresto flow is covered
gofood pricing kafka stream Go-Food Order Flow Components & Dependencies - Final allocation gofood oms driver platform good bye! thanks for everything. stanmarsh gofood order detail gopay-balance gopay-voucher gate termination service gofood cms order history goresto notification
Lesson Learnt • Migrate business flow • Faster to execute, minimize moving dependencies • Proving scalability: independent between flows (domain driven design) • Easy to control traffic for the rest of the flow • Split datasource first • To avoid data consistency potential issue • Staggered rollout • Load control • Isolating impact • Easy to rollback • Automated test • Defining the expected behaviour for the new service • Make development a lot faster • Eventual consistency • To avoid multi-dependencies transaction hell • Stable on sudden traffic • Monitoring and alerts • Visualize the traffic switching • Get failure feedbacks, enabling fast rollback
Thanks If you think this is a challenging stuff, just keep in mind that We’re always hiring. https://www.go-jek.com/careers/search/?type=function&search=engineer