“Platform” is an eagerly applied term in our Industry. Fortunately, The structure of platforms is well-understood and documented. The Ads-Trust team has been building a platform, which powers our applications. This platform has a similar structure, and was conceived by applying core software development principles and practices. In this talk we walk you through our journey, of applying theory in practice and the demonstrate the value it generates. “Platform” is an eagerly applied term in our Industry. Fortunately, The structure of platforms is well-understood and documented. The Ads-Trust team has been building a platform, which powers our applications. This platform has a similar structure, and was conceived by applying core software development principles and practices. In this talk we walk you through our journey, of applying theory in practice and the demonstrate the value it generates.

1. Ads Quality Platform :
Theory meets practice
Naveen Muguda & Dhruv Bansal

2. Ads Quality
• check compliance of ads before they are served

3. Ads Quality
• many reviewers, categorized into two buckets :-
• Software: ML models, content of ads(regexs, all caps, emojis, embedded
links), history of advertiser
• Human reviewers: Inspector/Review Queue.

4. • many ad types
• review logic can vary per ad-type
• review logic can vary over time

5. • certain ad types require permissions/certifications
• cost/capacity of reviewers need to be considered

7. Problems
• Each Reviewer has different schema to communicate with each other
and need to track all communication themselves.
• Difficult to track lifecyle of an ad
• Difficult to track performance of each reviewer
• Low developer productivity

8. Reviewer1 Reviewer2 Reviewer3 Reviewer4
AdType1
AdType2
AdType3

12. The platform provides the infrastructure and
tools on which others add value

13. Value is created in interactions between
suppliers and producers(roles)
The platform regulates and manages activity
by creating conditions for interactions

14. Platforms
Platform Producer Consumer Unit
Uber Driver Rider Ride
LinkedIn Candidate Employer Job
Airbnb Property Owner traveler Stay
Android /iOS Developer User App

15. Platform
Platform Producer Consumer Unit
Ads Quality Reviewer Ad-Type Review

16. • 7 * 5
• 9 * 8

17. • 17 * 29

20. Intuition = recognition

21. 9 * 8
System 1
System 2

22. 17 * 29
System 1
System 2

23. 17 * 29 with paper
System 1
System 2

24. hypothenuse
System 1
System 2

25. Pythagoras theorem
Right angled triangle
exponents multiplication addition
Triangle line
angle

26. hypothenuse
System 1
System 2

30. Selection
Projection
Boxes and Arrows
code
Reality

31. Maps(models) are valuable when they are precise and incomplete

32. Selection : Projection

34. Data Flow Diagram

35. Asynchronous communication

40. Orchestration vs Choreography

41. workflows

42. Model Driven Development

43. Ads Quality Platformisation
• Routing
• Tracking

44. COMMUNCATION
AND
ROUTING

45. Reviewer 1 requests Reviewer 2
to review
Producer Consumer

46. Reviewer 2 send response to Reviewer 1
Consumer Producer

47. Applying DRY on behavior of a Reviewer
• Communicates with each other asynchronously
• Each reviewers has a kafka topic with specific schema to get requests
to review
• Calls other reviewers with their different event schemas
• Receive Response In terms of an event from reviewers which were
invoked via kafka.
• Returns response to caller by sending an Event with some specific
schema like ReviewItemClosedMessage etc.

48. First Abstraction
• They have the port to review an ad.
• They have the port to get response from other reviewers.

49. Abstraction

50. Server
• public interface Server {
Task<Response> review(
@NonNull Reviewee reviewee,
@NonNull Actor client,
@NonNull ReviewSession session);
}
Reviewee - Ad information
Client – caller which request for review
Session – session of a review (guid)

51. Client
• public interface Client {
Task<Response> onReview(
@NonNull Reviewee reviewee,
@NonNull Actor server,
@NonNull ReviewSession session,
@NonNull ReviewDecision reviewDecision);
}
Reviewee - Ad information
Client – caller which request for review
Session – session of a review (guid)
Review Decision – decision of a server (target reviewer)

52. • Kafka Event Schema
• Address of target reviewer i.e. kafka topic of target reviewer
• Just have to know identifier of other reviewer
Reviewers should not care about

53. Communication Principle Used

54. TSCP Review Api Library
(Platform provided construct)
It has the responsibility of
• taking care of resolving target topic of kafka or may be restli endpoint
of target reviewer.
• It converts review request or review response into required common
kafka message schemas.

55. TSCP Review Api Library
(Platform provided construct)

56. Kafka Schemas
Only 2 avro schemas for communication across reviewers
• ReviewRequestMessage - details of ad, caller, header, sessiom
• ReviewResponseMessage – decision of a reviewer

57. Server Stub
Similar concept to RPC
• It acts as a server proxy
• Construct and send a
ReviewRequestMessage kafka message

58. Client Stub
Similar concept to RPC
• It acts as a client proxy
• Construct and send a
ReviewResponseMessage as a kafka
message

59. Reviewer Registry
• Resolver of client and server based on urn(namespace and id) of a
reviewer.
• It has list of all ports and corresponding kafka topics.

60. Reviewer and ReviewerRegistry

61. KafkaServerListener
• Responsible for listening ReviewRequestMessage
• Invoke Server’s review() method by converting message into java
objects

62. KafkaClientListener
• Responsible for listening ReviewResponseMessage
• Invoke Client’s onReview() method by converting message into java
objects

63. ReviewerGeneratorFactory
• Takes input as List of Reviewers
• Starts Kafka Client and kafka Server Listeners for
all reviewers with the help of ReviewerRegistry

64. ReviewerGeneratorFactory

65. Reviewer 1 requests Reviewer 2
to review
Producer Consumer

66. Reviewer 1
Tscp Review API library
Registry
Server
Stub
External
Shared
Config/DB
Mapping of kafka
topics of all
reviewers
Request another
reviewer to
review
ds
Kafka
ReviewRequestMessage
Phase 1

67. Converted to
Kafka
Server
Listener
Kafka
ReviewRequestMessage
ds
Kafka
Phase 2
Reviewer 2
+ review()
Converted to
ReviewRequest, Client,
Reviewee and invoke
review
ReviewerGeneratorFactory
+ List<Reviewers>
Starts
Registry
External
Shared
Config/DB
Mapping of kafka
topics of all
reviewers

68. Reviewer 2 send response to Reviewer 1
Consumer Producer

69. Reviewer 2
Tscp Review API library
Registry
Client
Stub
External
Shared
Config/DB
Mapping of kafka
topics of all
reviewers
Send response to
another reviewer
ds
Kafka
ReviewResponseMessage
Phase 1

70. Converted to
Kafka
Client
Listener
Kafka
ReviewResponseMessage
ds
Kafka
Phase 2
Reviewer 2
+ onReview()
Converted to
ReviewRequest, Client,
Reviewee and invoke
review
ReviewerGeneratorFactory
+ List<Reviewers>
Starts
Registry
External
Shared
Config/DB
Mapping of kafka
topics of all
reviewers

72. After platformisation

73. Tracking

74. Review LifeCycle Tracking
• Sidecar running separately being run by new multiproduct , Tscp-
Quality-Tracking
• Listening to all requests and responses using registry of tscp-review-api and
saves them into DB.
• Will be used to provide responses of one reviewer to other with
permission control via an API.

75. Tscp Quality Tracking(Platform)
Tscp Quality
Tracking
Tscp Review Api
Registry
Externa
Shared
Config/DB
Mapping of kafka
topics of all
reviewers
Get mapping
of
all reviewers
Kafka cluster
Listen to all requests
and
responses
DBSaves all requests
and responses
into DB
1
2
3