这是我在部门分享ppt的再整理。

0. 业务介绍

目前KTV主要包含了KTV在线预订和KTV酒水点单两个业务。

  • KTV在线预订

    KTV在线预订是用户在线浏览商家的包房信息,并选择相关包房的套餐,支付预订;订单支付成功之后,系统将通过多种渠道撮合用户与商户,使其达成预订;预订成功之后,用户到店消费之后,系统将费用结算给商家,同时系统也提供了退款的逆向流程。

  • 酒水点单

    向用户提供KTV商家店内超时购买服务,类似与短距离的外卖业务,只是配送距离据现在KTV商家内部;用户在KTV包房内,通过扫码即可浏览该商家提供的小吃及饮料,支付之后系统会通知商家,商家将很快送到KTV包房中。

基本功能

系统主要提供了供应链侧、用户侧、商户侧和客服侧等功能。

KTV预订用户端界面:

KTV预订商户端界面:

酒水点单用户端:

酒水点单商户端界面:

1. MVP阶段架构

MVP阶段主要是为了验证预订产品形态的可行性,因此这个阶段主要替代线下预订形式。

线下预订方式需要客人打电话给商家,在商家中确认商家的包房信息,比如包型、套餐、价格及库存情况,综合了解了信息之后用户才能觉得预订哪个包房,然后在电话中与商家协定预订;预订成功后,用户到店并支付消费。

在MVP时,产品上主要解决用户包房选择的问题和协商预订,因此系统上主要解决这两个需求。

1.1 架构选型依据

  • 包房选择

    主要结构化包房信息,套餐及价格等sku基础信息,供用户线上决策。

  • 预订

    系统上连接用户与商家。

  • 开发效率

    MVP阶段的系统唯快不破,需要最小的代价实现产品需求。

1.2 架构形态

架构上主要建立了商品系统和订单系统,支撑包房选择及预订需求。
这种架构非常简单,缺点也显而易见,但开发效率很高,后期产品形态调整时,系统也能很快变化。

2. 业务推广期架构

MVP阶段初步实现了预订形态,但却有许多需要优化的问题:

2.1 到店保证

整个预订过程没有支付保证,很多用户预订成功之后,可能不会去消费,也不会在线上取消预订,导致商家成本升高。

2.2 线下交易

  • MVP阶段只是部分取代了传统预订,体验上还需要优化;
  • 因为用户没有支付,导致平台也无法整个交易过程,会导致用户和商家的利益损失;
  • 整个流程没有交易数据产生,对平台的发展不利。

因此需要解决交易闭环的问题,这个阶段引入了预付

2.3 挑战

预付:用户在下单后,需要支付成功之后,系统才会扣除商家预给的包房库存,从而达到预订成功,之后用户直接到店消费即可。
因为引入了支付,因此需要消费、结算及退款需要配套。

这个阶段主要这些挑战:

  • 业务快速推广
  • 预付
  • 退款服务
  • 确认到店
  • 包房库存。

且在分析需求之后可以得出一下预期:

  • 可以确定的:

    订单、预订、消费和退款是独立的业务领域;
    退款需要记录退款时间及退款金额等,并控制退款流程;
    消费需要记录发起消费时间,及发起人等凭证信息;
    业务还会继续演化。

  • 可能发生的:

    订单、预订、消费和退款内部逻辑会变得更加复杂

2.4 架构选型

在当时我们会有图中两种方式。因为订单、预订、消费和退款内部逻辑相互独立,且退款及消费需要记录凭证数据。

如果采用订单扩展的方式,则需要在订单上扩展许多字段,甚至新建相关的表。采用完全独立的方案,系统实现上比较清爽,是程序员最喜欢的方式,但开发量较大。

但这个阶段,业务需要快速推广,开发效率是我们最高优先级考虑。因此这两个方案都不能很好的满足,因此需要一个中间方案,既能一次开发效率高又能扩展性较好。因此在架构上做了一些牺牲。

2.5 架构

在这里将服务划分开,退款和消费因为需要记录必要的凭证因此,退款和消费都有独立的数据模型;但为了降低开发量,因此业务流程依然集中到订单服务来控制。

3. 快速发展期架构

3.1 挑战

  • 线上库存与线下预订

    销售拿到的库存并不能反映商家线下真实库存情况,而且商家出了接待预订订单之外还需要接待线下电话和团购等渠道的客人。

  • 商户接单效率

    • 商家在不同时间的接单意愿是不同的,比如节假日和工作日商家;
    • 商家的管理系统与线上系统脱节
    • 用户取消订单后需要与商家及时联络。

    综合分析,在业务上需要提供更丰富的接单及订单处理能力。

因此在这个时期的业务主要面临三个方面的挑战:

  • 预订业务流程复杂

    依次新增了商家接单、系统直连模式和售中接单等,各模式之间交互复杂,各接单模式之间还会相互影响。

  • 需要支持多个服务商的系统直连

    新增了系统直连之后,需要与多个服务商对接。

  • 退款流程复杂

    退款流程引入了审核流程,审核流程中有售后客服和商家两个角色,且需要支持更多退款类型,未来还有可能扩展,不同的退款类型有不同的业务逻辑。

3.2 解决问题

  • 系统直连标准化

    制定系统直连标准,抽象对接接口、系统超时重试和异步化,体现在系统架构为:

  • 预订流程抽象

  • 退款流程抽象&模版化


3.3 架构变化

4. 稳定生长期架构

4.1 挑战

KTV 在线预订经过了三个时期的发展已经进入比较成熟的时期,这个时期我们又孵化了新的业务类型——酒水点单。
酒水点单在业务形态上是KTV店家内部的外卖业务,购买的是KTV超市内的商品。

这个时期的挑战主要是如何快速的支撑新的业务类型。

4.2 解决问题

4.3 架构变化

5 总结

这是对KTV业务交易侧的一个整体总结,后面会转入新的业务中。