Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MongoDB at Work: Converser

oisin
November 03, 2014

MongoDB at Work: Converser

How Converser used MongoDB, and more importantly, where we made mistakes.

Talk given at Mongo Days, Munich, in November 2014

oisin

November 03, 2014
Tweet

More Decks by oisin

Other Decks in Technology

Transcript

  1. Smarter marketing for mobile apps converser • A Mobile Marketing

    Channel for your apps — interactive messaging, segmentation and analysis
  2. Smarter marketing for mobile apps • Media-rich and interesting interactive

    messaging • Designed to help app users make quick decisions and gather data • Allows the conversation to be structured to directly contribute to your marketing strategy
  3. Smarter marketing for mobile apps • Mobile SDKs for iOS

    and Android • Tools to design your own conversations and deliver them to your mobile users • Straightforward analysis of app interactions and data export
  4. Smarter marketing for mobile apps our customers • marketing teams

    seeking tools to make mobile a primary channel for access to their users • cross-verticals — customers in publishing, banking, semi-states, utilities, marketing companies, media
  5. Smarter marketing for mobile apps choosing mongo • challenge: make

    a business that can start fast and deliver product quickly • founder experience: strong development and product construction skills • task: what storage technology to choose, given so many choices
  6. Smarter marketing for mobile apps constraint: flexible data • learning

    while doing, and shipping while product still very much in flux • data models not optimised for unknown typical interactions — and changing typical interactions • user data variable - depends very much on application • faster to react to business changes
  7. Smarter marketing for mobile apps constraint: support • The time/money

    balance — how much time do we spend to be experts, is there help? • An option on hosting important — agency that look after upgrades, downtime, setting up replication, etc. • An option on knowledge support — easily accessible experienced organisations • A lot of freely available information, solid language bindings
  8. Smarter marketing for mobile apps Architecture principle: minimum number of

    moving parts, no introduction of things without good cause Actors Scheduling Messaging Mongo Redis App Servers Mobile Servers
  9. Smarter marketing for mobile apps the basics • maintain a

    subscriber list for all of the apps we represent (about 500 apps, 4.5m subscribers) • maintain an inbox for each subscriber — drop messages in there for users • gather data/events from mobile devices and track • analyse interactions and present as report • respond to automation request from external systems
  10. Smarter marketing for mobile apps data and privacy • Privacy

    and data location • private infrastructures for banks and semi-states • EU/US zone residency for data, with no connection between • Operational ease offered by MongoDB is helpful
  11. Smarter marketing for mobile apps mistakes • “That collection will

    only get to about 20k documents when we have a thousand active customers” • “Those indexes should be fine now” • “I used an array for that” • “This changes depending on message status, yes it’s an index” • “Seriously, you can do anything with map-reduce”
  12. Smarter marketing for mobile apps arrays: alternative • read time

    tax about 10% • writes to inboxes 8x faster
  13. Smarter marketing for mobile apps successes • Straightforward for full

    time dev, part time ops tiny team • Performs well once we fixed our mistakes • High quality support • Tooling is getting really good
  14. Smarter marketing for mobile apps future tense • Cloud-managed MongoDB

    • Per document locking in 2.8 • Sticking with MongoDB as a key part of our infrastructure
  15. Smarter marketing for mobile apps rules of thumb • keep

    an eye on slow queries always • indexes, choose them wisely and review • do not index fields that will change • arrays — only if they are fixed size, and allocate up front • prefer queries/aggregation to map/reduce • test collections to 50x the size you expect them to be