Design Programmatic Digital Advertising Trading bidding platform
Designing
Use Cases:
1. Only pay for impression that meet the context and criteria that customer select
2. Increase reach to multiple sites by spreading customer budget across them, instead of purchasing thousands of impressions on one page.
3. Scale campaigns easily using millions of data points.
4. Support Use role for Admin, Seller and Buyer.
5. Track analytics return of investment in historical and real time.
6. Service has high availability.
Out of scope:
1. No predefined targeting segment load to the system.
2. No real time custom targeting estimation report.
3. No search of the ads contents and description.
4. Support only many Ads Exchange.
5. No Payment System is needed.
Constraints:
1. Bid Request Demand is a lot higher than Serving Impression request (200 vs 1).
2. Daily 50–100 Campaign, Each Campaign has 50–100 Flights, Each Flight has 2–5 Creatives to serve.
3. Low latency for bidding response and fetch correlated campaign, flights and creative
Usage Consumption:
Get Kevin Mo’s stories in your inbox
Join Medium for free to get updates from this writer.
1. 100 Campaign * 100 Flights * 5 creatives = 50000 bid Request (Read request)
2. 200 Bid vs 1 impression = 250 Impression serve request (Read Request)
High Level Design:
1. Campaign, Flight, Creative (Write Request) is comparative lower than Bidding and Impression Serving request (Read Request).
2. Track Analytics (Write Request) to Database or Queue will also be same as Read Request. We can only log the impression request that successfully fulfill the criteria.
3. Stateless server connection is recommended because there is no need to keep the state in the client to server for long period of time.
4. A set of web server to handle incoming request and using load balancer in front of it. Round Robin of strategy of the request to the servers should be sufficient to balance the incoming load.
5. Cache on Campaign, Flight, Creative and other static content such as (html, javascript, image) is recommended.
6. Suggest to use structure database (MySQL) to store transactional USER actions, (PAYMENT is any) and use NOSQL database to store unstructured data (analytics data, flight criteria selection).
7. Filtering logic stores in the core component services to save the servers route trip time.
8. Pacing on different criteria (CPM, Budget) the incoming impression and spare the across entire campaign is needed
9. Filter the various targeting criteria base on the audience level.
10. Message queue to deliver asynchronous message to various micro-services (pacing, user service and others). Real time data engine to process real time data.
11. Use TTL in the NoSQL database to set the 12–36 months expiration of the record.
12. CDN provides static contents such html, javascript, static images etc.
13. DNS provides domain names service lookup.
14. Web server provides API request and database lookup.
15. Analytics server collects metrics, stats and monitoring services.
16. Mem Cache provides fast lookup for the READ API.
17. Pacing services provides pacing for the campaign.
