This document discusses different approaches to interoperability between Scala and .NET systems, as used at Adform SSP. It describes using APIs, queues, and shared databases for interop. APIs work best when contracts are defined separately and tested thoroughly. Queues require careful versioning of contracts. Shared databases are easiest within a single team due to administration challenges. High performance requires minimizing request sizes and testing serialization. Cross-functional teams facilitate interop but coordination is difficult.

1. Interop between Scala & .NET
ivan.antsipau@gmail.com

2. • Interoperability is a property of a product or system, whose
interfaces are completely understood, to work with other products or
systems, present or future, without any restricted access or
implementation
• "The capability to communicate, execute programs, or transfer data
among various functional units in a manner that requires the user to
have little or no knowledge of the unique characteristics of those
units”
[1] https://en.wikipedia.org/wiki/Interoperability

3. How to Interop
• API
• Queues
• Shared Database
• In-Process

4. Context: Adform SSP
• Over 11k QPS
• Real-time Auction
• Low latency:
• 170ms hard requirement for Auction
• 150 – 300ms max from browser
• 3 locations: DK, US, Hong Kong,
• 6 DCs

5. Example
GET http://adx.adform.net/adx/?mid=165310
document.write('x3Cscript
src="http://track.adform.net/adfscript/?
bn=11736758;rtbwp=2gzaFnw8s0bDeIjrSAcYFw
2;rtbdata=x49-XKco2ljteFvAjwmBR8VZZ-
ecm_HJD42Fn25lTKXETZ1-
WPfAGURdizw_wH7GMmMNdHuK2djcV3YLzMm9gAlw
sDQC8oMGWYQE7mVjhr1v7UVP32pv6ZKe7IERNzp-
Kexo8ut86xg1;csid=24503;icid=123456789;i
cidt=635942828974512852;adxvars=EAp6I9xH
g2XSNJlw0KnxBTNBQTXLUgMDtmuBlq5I2aHbQI-
qizNBG9tR1EaLwCYw-
Uh9xhg6GXFKXUHana4VLHqH_0hvFUZGEJJ9ZdCF0
cJXdzFaFEisL0uukdidDOtnSrZoi7LaZzFmbLpZw
feEp9fesWLFaQa3LbXiwETOB-
PF4uDLN0eu3oDFVLyQqT58FFxtWn3aByo1;adxcm
d=QTwuOIuaMWwDvP-
67D9Y4w2;compoundseqno=1;compoundimpr=1;
" type="text/javascript">x3C/script>');

6. Request Lifecycle

7. Components
• ADX:
• C#, .NET, IIS, HttpApplication
• DK: 12 x Windows Server 2008
• Puppet, powershell
• Auctioneer:
• Scala, finagle
• DK: 5x CentOS
• Fabric
• Monitoring:
• ELK, Graphite, Grafana
• Alerting:
• Bosun

8. API Calls
• Contracts Redistributable:
• No duplication, self-describing
• In-code contracts:
• code duplication
• but works better for 2 components
namespace Adform.Adx.Entities.AdExchange.Contract
{
[JsonObject(MemberSerialization.OptIn)]
public class SspRequest
{
[JsonProperty(PropertyName = "request_id")]
public string RequestId { get; set; }
[JsonProperty(PropertyName = "cookie_id", DefaultValueHandling
= DefaultValueHandling.Ignore)]
public long? CookieId { get; set; }
read.`object` {
case "request_id" => requestIdOpt = read.nextNonEmptyString
case "cookie_id" => cookieId = read.nextLong

9. API Calls Considerations
+ Easier releases and maintenance
(-)Request size grows, performance decreases
(-)Internal Network may becomes an issue
• Benchmark your tool for sending requests
• Additional Infrastructure to maintain
• Need to support service discovery
• Contracts redistributable vs code duplication
• Test serialization for corner cases

10. Measure latencies on both ends
Constantly tweak both components to
maintain performance

11. Cookie Matching

12. Shared DB: Real-time data (cookie matches)
Adform Cookie Matching
Browser
Aerospike
Browser ADX
Auctioneer DPS1, DSP2
DSP Cookie Matching

13. Shared DB
• Super fast
• No additional infrastructure
• Hard to update
• Works fine only when contained in one team:
• Administration DB vs AERD
• Otherwise switch to APIs

14. Queues
impressions
Aerospike
Ad Serving
trackingPoints
Kafka
Adx
TransactionLoader
Budget Service
API

15. Protobuf
message SspAuctionResult {
required Decimal win_price_in_party_currency = 1;
required Decimal win_price_in_inventory_currency = 2;
required Decimal win_price_in_eur = 3;
optional string deal_id = 4;
optional int32 creative_setting_id = 5;
optional int32 package_id = 6;
required string winning_bid_id = 7;
}
Nexus (jar)
proto
Nuget (dll) app1
app2

16. Queues Considerations
• Keep contracts in separate repo
• Backwards compatibility issues
• Enums may have issues
• Weak control who subscribes

17. Process
• Cross-functional team:
• Rare, need to grow in-house
• Individual teams:
• Individual backlogs
• Coordination sucks
• Debugging issues is a nightmare
• Expertise allows participating in non-.net projects:
• Storm, SPARK
• (-) different devops tools

18. Thanks for Your Attention
ivan.antsipau@gmail.com

19. Plan
• Definition
• Adform General, History, Adform SSP
• Types of Interop we use:
• API
• Queues
• Shared Database
• No In-Process
• API:
• Contracts (keep in separate repo or keep double definition)
• Check corner cases, unit-test contracts.
• We like double definition for simple scenarios
• High Performance, low latencies: be careful about request sizes, test the tool for corner cases
• Measure from both ends
• Queues:
• Protobuf, backwards compatibility issues, enums
• Shared DB:
• Good when inside a small team, disaster otherwise, consider only performance-wise
• Challenges:
• Cross-functional developers
• Separate backlogs otherwise
• Easy when different teams
• Different DevOps solutions
• Always use the same metrics/operatins tools as much as possible