Session Title Designing Softwares for Extensibility Rupesh Agrawal Merpay Backend Engineer 

Rupesh Agrawal / @Rupesh Specializing in Software product development, Rupesh has worked at multinational companies, primarily in the B2B domain. His career has afforded him experience with product development in telecom billing and IT infrastructure management. Rupesh joined Mercari in 2021 as a Backend engineer and later led the development of a marketing platform named Engagement Platform. Merpay Backend Engineer 

What is Software Extensibility ? https://en.wikipedia.org/wiki/Extensibility 01 Adapt to changes without major refactoring 02 Extensibility ~ Configurability 03 Extensibility ~ Scalability 04 

Building a product or platform => longer lifetime (decades) 01 The target business domain is vast, current development is not 02 Not all the use cases are known in advance 03 Support integration with 3rd party softwares 04 When Extensibility is needed? 

Solution vs Products/Platform Solution ● Requirements are collected at initial phase ● Tailor-made for the requirement ● Extensibility is not the prime focus ● Best if the time or resources are deciding factor ● Short lived Product/Platform ● Requirements are groomed continuously ● Room to grow and shape ● Extensibility is must ● Best when having a clear vision of roadmap ● Evolves with time 

But, how do we do it ? 

Identify the Modules and their responsibilities 01 For each module, Identify the entities and their relationship 02 Define Interfaces with composite types and not primitives 03 Volume projection, it is important to decide inter-service communication mode 04 How ? 

Case Study: Engagement Platform 

In house platform, envisioned to serve all the growth needs 01 Started with use case of distributing coupons on user signup in realtime 02 Could have been done with much simpler piece of code 03 The core design was considered to support extension 04 Engagement Platform Provides Brand(Mercari) to users communication for happy and long-lasting retention(growth). 

Segment Campaign Distribution Hub Points Coupons Notifications 

Considerations made while desgining Loosely coupled modules 01 Entity Modelling considering possible scenarios. 02 Composite objects in Request and Response 03 04 Defined scope of each of the constituting services and 05 Strategy to communicate between services 

Data Model - Identifying entities Campaign - Models any kind of communication with customer 01 Segment - Users who qualified certain conditions 02 Incentives - Rewards or discounts to be granted 03 04 Notification - The communication going to the Users 

Data Model - Entity Relation Campaign - Defines any kind of interaction with custimer 01 Segment - Target Users for the Campaign 02 Incentives - What rewards and incentives 03 04 Notification - The Notifications and messages going to the Users 

Example: User Onboarding Campaign Welcome user with P1000 on registration 01 Once they have listed an item reward them with a seller coupon 02 They have sold something (utilizing the seller coupon), reward them a Buyer Coupon 03 04 (Each of these steps can have different notification channels) 

Campaign Segment -1 Segment -2 Segment -5 Incentive Notifications[] Incentive Notifications[] Incentive Notifications[] Registration Listing Selling 1000P Sellers Coupon Buyers Coupon Private Message Push Notifn InApp Msg Push Notifn Private Message Example - Campaign Visualization 

Event processing strategy All event processing designed to happen asynchronously 01 Events Idempotency made retry & recovery possible in case of failures or duplication due to underlying infrastructure. 02 Event state logging on service level to assure traceability 03 04 Synchronous calls only for campaign configuration 

How it helped : Enhancements Point distributions along with coupon distributions 01 Number of times a user can be rewarded , 1 or N 02 Max amount a user can be rewarded with 03 

Supporting Batch Distributions of Incentives Not something we originally planned for !! 01 Change the Segment definition : User events to Query 02 Required to support event bursts, as real-time events are more continious 03 New challenges : flow control, and event prioritization !! 04 

Supporting Notifications Only distributions Originally Notifications attached to rewards were only supported 01 02 The Campaign model already supported it, with minor adjustments, we could deliver this ! 03 Originally sought for Batch distributions, modular design made it available for real-time campaigns as well ! Originally sought for Batch distributions, modular design made it available for real-time campaigns as well ! 

What it mean to run such software 

Check Maintain Backward compatibility 01 02 Good user documentation: so that they can onboard themselves 03 Security and controlling data access across user groups 04 Monitoring and continuity : One failure can impact multiple Business Offering 

No content