Here is solutions for Segmentation Platform of Grab.

1. What is it ?

• When a passenger launches the Grab app, our in-house experimentation platform will tailor the app experience based on the segments the passenger belongs to.

• When a driver-partner goes online on the Grab app, the Drivers service calls Segmentation Platform to ensure that the driver-partner is not blacklisted.

• When launching marketing campaigns, Grab’s communications platform relies on Segmentation Platform to determine which passengers, driver-partners, or merchant-partners to send communication to.

2. What is 2 flows ?

Segmentation Platform comprises two major subsystems:

• Segment creation
• Segment serving

2.1. Segment Creation

• Admin tool -> Spark job -> Data Lake -> Segment.

2.2. Segment serving

• We chose to use ScyllaDB as our NoSQL store due to its ability to scale horizontally and meet our <80ms p99 SLA.

• The table is partitioned by the user ID ensuring that segment data is evenly distributed across the ScyllaDB clusters.

User ID	Segment Name	Other metadata columns
1221	Segment_A	…
3421	Segment_A	…
5632	Segment_B	…
7889	Segment_B	…

3. What are problems ?

P1: The segment is created long-time.

P2: Request low lagency when check membership.

4. What is solutions ?

4.1. Segments as bitmaps (Denormalized into new column)

Cons:

• For example, if a segment contains 2 user IDs 100 and 200,000,000, it will require a bitmap containing 200 million bits (25MB) where all but 2 of the bits are just 0.

4.2. Roaring Bitmaps (Solve fragment storage, segment by range)

4.3. Caching with Redis Layer for hot segment

5. What are teams to implement it ?

5.1. Communications Platform

• Using the SDK, the team is able to perform membership checks on multiple multi-million member segments, achieving peak QPS 15K/s with a p99 latency of <1ms.

5.2. Experimentation Platform

• Prior to using the SDK, Experimentation Platform limited the maximum size of the segments that could be used to prevent exhausting a service’s memory.