Code Driven NYC: P2P #Security, #DistributedSystems, #AI system
Posted on June 22nd, 2015
06/22/2015 @Bluecore, 124 Rivington St, NY
Three speakers presented at the initial meeting of @CodeDrivenNYC:
• Max Krohn, founder of Keybase (previously founder and CTO ofOkCupid and SparkNotes): “The Quest for User-Friendly Crypto”
• James Socol, Platform at Groundwork (and formerly of Bit.ly / Mozilla): “Lessons Learned Building Distributed Systems”
Each talked about topics that are uniquely of interest to developers. These include design of systems and development decisions such as choice of language and database for a particular application.
Max @Keybase talked about steps needed toward greater security on person-to-person communication over the internet. He first divided internet communications into two types:
- You communicate to a central location
- Person to person communications
Banks and other financial institutions have developed secure communication methods to and from a central location. However, person-to-person communications still do not have that level of security. Max then spoke about the p2p challenges we face
- Public identity – how do we know that “Bob” is “Bob” before you get their public key -> maybe virally recruiting users solves this problem
- Secret key manager – “Bob” cannot control his keys – it’s hard to move it to all devices. Also you can lose the code or lose a device on which you key is stored.
- Simplified polished app – the general user population will not use anything other than an easy-to-use utility.
James Socol, formerly @Mozila and @Bitly, spoke about the lessons he has learned building distributed systems at Bitly. The system challenges at Bitly (the business model is covered in notes on Bitly) including handling 230B click every day. This can only be done on a distributed system. Characteristics of this system include:
- Concurrency of components – but can be hard to coordinate
- lack of a global clock – server clocks can drift and become out of sync
- independent failure of components – do you make sure things are done even if as service is temporary unavailable
To master such as large system each task must be small and focused, preferring a multitude of cheap, generic components over a small set of expensive parts. Methods to handle this system include
- Async is better than synchronous, but it’s important to know your requirements to determine which components can be run asynchronously. For instance, critical path items need to be synchronous (e.g. creation of the shortlink).
- Events are better than commands – events flow one way, commands need a response. Its better to concentrate on what happened than who asked for it and how to respond to the request.
- Annotations are better than filters – keep everything since it might be used later e.g. geocode everything and filter downstream.
- Dealing with failure – deal with backpressure with retry mechanism. Need monitoring to know where there is an issue.
The last speaker, Alex Poon @x.ai (use AI to create an agent to negotiate and schedule meetings – the business model is covered in my notes on x.ai) talked about the language and architecture decision when creating the system.
They use Scala and JS: Scala for intense processing. JS for UI and to leverage AngularJS.
They use Mongo as the DB as it is schema-less (and good for development as they are not prematurely locked into a structure as they develop the product). They use the Mongoose library so the DB is accessible from both Scala and JS.
They use a queue-based architecture : web apps -> AWS -> AI allocators -> classifiers. They can accept some delays in the queue since they can accept deviations from a strictly real-time system.
They use RESTful APIs using JSON to communicate across processes.
Alex noted that over time certain features have migrated from JS to Scala to take advantage of Scala’s AI engine since some of the business logic has become more complex over time. One example is a “surrender meeting” : if your friend does not respond to requests there is some point at what time do you give up trying to schedule the meeting.