之前参与过商品体系建设，对于平台型电商来说，万物皆可商品，商品管理主要的复杂度体现在不同行业不同类目的上单流程区别、商品属性差异，由此带来的标准化治理问题，以及类目属性体系的沉淀。
一言以蔽之，商品、仓储等领域的复杂度主要在B端，C端业务场景相对简单，而营销不同，主要的业务变化在C端，复杂度来自于不断变化的营销形态。
技术为业务服务，那么面对营销这样一个形态多变的业务，应该如何去进行系统设计呢？
下面从模型、性能以及选型进行展开。
1.模型
杀一个程序员不用枪，改三次需求就好了。
这句话当然是一个段子，不过也说明了，大部分工程师不太喜欢「频繁改需求」这件事情。
但是，大部分互联网业务，改需求这件事情是非常合理的，特别是电商营销的场景里，需要及时反馈，及时调整营销策略，「改需求」几乎是必然的。
有经验的工程师都知道，工程开发里底层模型的稳定性非常重要，良好的底层数据结构，可以预留扩展空间，好像杠杆一样，支持更多的业务发展。
如果不能用一个相对稳定可扩展的模型去承接上层业务，开发很容易就陷入到无尽的需求调整中去。
那么在底层模型上，就需要进行一定的抽象，对于优惠券、活动等的数据模型设计，可以从以下方面展开：
各类营销工具的实体，是否需要落地数据模型？
各类促销规则，是否可以全部枚举出来？
不同的促销规则，规则之间的关系如何处理？
这里要避免一个误区，就是过度抽象和设计。
电商领域设计里，有一个抽象程度特别高的模块，就是风控。
在进行风控系统设计时，要考虑各类交易属性，对应触发的阈值，以及风控动作。但是营销和风控有一个很大的区别：
风控策略是由平台管理，而营销工具的使用者是商家。
也就是说，营销工具，不可能做成像风控一样，是字段和规则的自由组合。B端产品的功能设计，就是营销模型抽象的一个边界，在设计数据结构时，要考虑到营销工具给商家操作时的易用性。
2.性能
营销系统的另外一个技术挑战是性能，例如各类促销活动的实时结算，秒杀系统的性能优化。
目前一类电商的营销玩法越来越复杂，特别是大促活动期间同一个商品可能叠加了七八个不同的营销。这些都需要在购物车里进行实时的计算，对整体的性能、并发量都有非常高的要求。
电商营销中秒杀系统的设计，是一个经典的高并发工程设计范例，各种极致优化手段基本上都应用上了。
3.选型
最后盘一下，营销侧开发需要哪些技术组件？
完成了模型的拆解，以及对性能指标的要求，就可以进行具体的技术选型。
Web框架，RPC中间件，以及关系型数据库等组价，普适性比较高，这里就不展开了，说一些比较特殊的。
优惠券都会有一个可用时间，超出之后，会被置为已超期，根据时间变化来调整状态，可以通过延迟队列来实现，Redis，MQ都可以实现
对于不同的营销活动，可以在前端引入一个状态，比如优惠券超期失效，逆向生效，状态的流转，可以通过状态机去管理
不同的规则之间是兼容还是互斥，需要一个规则引擎的支持，根据业务规模，可以选择使用Drools或者EasyRule，也可以自己开发
对于促销规则的表示，为了更灵活的进行抽象，可以使用脚本语言进行封装，比如阿里的QLExpress，mvel语言
在逆向流程里，会有比较多的异步任务，比如发生交易退款以后，退回优惠券，可以考虑使用消息队列等
促销的展示和促销价格的计算，对性能要求很高，需要各级缓存的支持，考虑Guava和Redis
C端接口需要考虑防刷，可以考虑添加限流降级功能实现稳定性，使用Guava-RateLimiter或者Alibaba Sentinel等
在优惠券领取时，需要避免超发，如果并发比较大，可以添加分布式锁实现
