BigDoor on Twitter BigDoor on Facebook Google+ Subscribe to the BigDoor blog feed

Enter your email address

Delivered by FeedBurner

BigDoor gamification in action!

Archives

Categories

Items

Archive | Improvements

BigDoor Goes Big with Performance Upgrades

April 12, 2013 by

As I write this, 50MM monthly active users are engaging with the BigDoor platform across our publisher sites. For a company that started with the simple idea of making online experiences more fun and engaging, knowing that our platform reaches that many people is astounding. As we launch more and more gamified loyalty programs with larger audiences, the importance of our platform’s performance and scalability has increased as well. To stay ahead of our publisher’s needs, we’ve been making major updates to our tech stack, ensuring that our platform comfortably supports the 20MM user actions per day and 1.5MM users who access BigDoor programs during peak hours.

Knowing that our platform integrates with the websites of some of the most influential brands across multiple industries might keep some of us up at night, but it also drives us to constantly push the envelope in terms of what our clients can expect in terms of features and performance.

In the past six months, we implemented significant performance improvements resulting in an average API latency of less than 250ms.

Visitors to any of our publisher’s sites continue to consistently and reliably enjoy our end-user experience. We’ve met 100% of our SLA’s high availability requirements this year, exceeding our 99.9% uptime goals for every month in Q1.

But, we are overachievers and we aren’t done yet.

On Wednesday night, we notified our publishers and Twitter followers that the BigDoor platform would be temporarily unavailable for an hour of maintenance. The maintenance window was required for the deployment of a new version of our backend database sharding framework, which will allow us to support even higher availability, increased responsiveness and more scaling capacity for our ever-increasing audience sizes.

The updates to our backend systems have only been in effect for a short time, but we are pleased with the results they are showing already.

Posted in: Blog, Improvements, Technology, UI

Announcing BigDoor’s Newest Platform Feature: Internationalization

March 27, 2013 by

In response to a growing number of current and future partner’s inquiries and suggestions, we are very excited to announce BigDoor’s newest platform feature: Internationalization.

Working with brands that achieve global reach, we acknowledge the need for rewards and loyalty programs that engage customers internationally and across languages. Unlike other vendors in the space, touting their “global” or “world leading” platforms with English-only language support, BigDoor has always prided ourselves in making our platform available in any language, but we weren’t satisfied with the complex translation progress that slowed down our typical implementation process. We decided to launch internationalization to enable brands around the world to easily implement a BigDoor Gamified Loyalty Program in any language (or combination of languages).

With internationalization the BigDoor user interface will reflect browser-specified  languages allowing visitors to seamlessly interact with a brand’s loyalty program, no matter what language version of the site they are on. Badges, quests, rewards and achievements will display in the browser-specified language throughout a customer’s session. The feature will also cover BigDoor powered redemption emails, ensuring that the entire BigDoor experience is available to customers, no matter what language they are using.

BigDoor publishers will be able to add language configurations to current loyalty programs, without affecting the existing experience. The internationalization feature will also allow publishers to break down existing analytics by language, giving even deeper access to valuable customer data and insights.

To learn more about BigDoor’s internationalization feature, or to talk with a BigDoor Loyalty Expert, please contact us at: Info@BigDoor.com.

Posted in: BigDoor news, Blog, Improvements, Loyalty, Technology, UI, Uncategorized

BigDoor’s Jeff Malek Talks Databases and Horizontal Scaling

September 18, 2012 by

When talking to people about BigDoor, we often get asked about our backend database systems. Potential clients want to know whether or not our system can handle their traffic (yes, it can) and other start-ups want to know how we scaled to handle the high traffic levels of our awesome clients. We thought it would be useful to give a little bit more information about our system as well as share some of the things we learned in the process. There is no better expert in this topic than our CTO/Co-founder Jeff Malek. He took a break from working his daily magic to give some perspective and advice. 

A friend was recently asking about our backend database systems.  BigDoor’s  systems are able to successfully handle high-volume transactional traffic through our API coming from various customers, having vastly different spiking patterns,  including traffic from a site that’s in the top-100 list for highest traffic on the net.   Don’t get me wrong; I don’t want to sound overly impressed with what our little team has been able to accomplish, we’re not perfect by any means and we’re not talking about Google or FaceBook traffic levels.  But serving requests to over one million unique users in an hour, and doing 50K database queries per second isn’t trivial, either.

I responded to my friend along the following lines:

  1. If you’re going with an RDBMS, MySQL is the right, best choice in my opinion.  It’s worked very well for us over the years.
  2. Since you’re going the standard SQL route:
    1. If your database is expected to grow in step with traffic, and you’re thinking about sharding early – kudos.  You’re likely going to have to do it, sooner or later.
      1. Sooner vs. later if you’re in the cloud and running under its performance constraints.
      2. Do it out of the gate, if you have time, after you’ve figured out how you’re going to do it (i.e. whether you’re going to leverage a tool, DYI, etc).
        1. In other words, if you have time, don’t “see how long you can survive, scaling vertically”.
          1. Sharding while running the race : not a fun transition to make.
      3. I realize what I’m saying is counter to popular thinking, which is “don’t shard unless you absolutely have to”.
        1.  Without the assumption that your data set is going to grow in step with your traffic, I’d be saying the same thing.
    2. Designing your schema and app layer for sharding, sharded on as few keys as possible, ideally just one, is not future-proofing, it’s a critical P0.
  3. Since you’re going to be sharding MySQL, your options are relatively limited last I checked.
    1. Ask for input from folks who have done it before.
    2. The other sharding options I started looking at over two years ago all had disallowing limitations, given our business model.
    3. At quick search-glance just now, it also does appear that dbshards is ruling this space at this point.
  4. So barring any other options I’m missing, your best options that I’m aware of:
    1. dbshards
      1. Definitions we/they use, to help clarify discussion  :
        1. global tables : tables that contain the same data on every shard, consistency managed by dbshards.
        2. shard : two (primary and secondary) or more hosts that house all global table data, plus any shard-specific data.
        3. shard tree : conceptually, the distribution of sharded data amongst nodes, based on one or more shard keys.
        4. reliable replication : dbshards-proprietary replication, more details on this below.
      2. pros
        1. The obvious : you’ll be able to do shard-count more reads and writes that you’d otherwise be able to do with a monolithic, non-sharded backend (approximately).
          1. Alternatively, with a single-primary read-write or write-only node, and multi-secondary read-only nodes you could scale reads to some degree.
            1. But be prepared to manage the complexities that come along with eventual read-consistency, including replication-lag instrumentation and discovery, beyond any user notifications around data not being up-to-date (if needed).
        2. It was built by folks who have only been thinking about sharding and its complexities, for many years
          1. who have plans on their roadmap to fill any gaps with their current product
            1. gaps that will start to appear quickly, to anyone trying to build their own sharding solution.
              1. In other words, do-it-yourself-ers will at some point be losing a race with CodeFutures to close the same gaps, while already trying to win the race against their market competitors.
        3. It’s in Java, vs. some other non-performant or obscure (syntactically or otherwise) language.
        4. It allows for multiple shard trees; if you want (or have to) trade in other benefits for sharding on more than one key, you can.
          1. Benefits of just sharding on one key include, amongst other things, knowing that if you have 16 shards, and one is unavailable, and the rest of the cluster is available, 1/16th of your data is unavailable.
            1. With more than one shard tree, good luck doing that kind of math.
        5. It provides a solution for the auto-increment or “I need unique key IDs” problem.
        6. It provides a solution for the “I need connection pooling that’s balanced to shard and node count” problem.
        7. It provides a solution for the “I want an algorithm for balancing shard reads and writes”.
          1. Additionally, “I want the shard key to be based on a column I’m populating with the concatenated result of two other string keys”.
        8. It has a distributed-agent architecture, vs. being deeply embedded (e.g. there are free-standing data streaming agents, replication agents, etc instead of MySQL plugins, code modules, etc ).
          1. Provides future-proofing, scaleability and plug-ability.
          2. Easier to manage than other design approaches.
        9. Streaming agents allow you to plug into the update/insert stream, and do what you like with changes to data.
          1. We use this to stream data into Redis, amongst other things.  Redis has worked out very well for us thus far, by the way.
          2. Other dbshards customers use this to replicate to other DBMS engines, managed by dbShards or not, such as a column store like MonetDb, InfoBright, even a single standalone MySQL server if it can handle the load.
        10. It supports consistent writes to global tables; when a write is done to a global table, its guaranteed to have been done on all global tables.
        11. It doesn’t rely on MySQL’s replication and its shortcomings, but rather on its own robust, low-maintenance and flexible replication model.
        12. Its command-line console provides a lot of functionality you’d rather not have to build.
          1. Allows you to run queries against the shard cluster, like you were at the MySQL command line.
          2. Soon they’re releasing a new plug-compatible version of the open source MyOSP driver, so we’ll be able to use the same mysql command line to access both dbShards and non-dbShards managed MySQL databases.
        13. Its web console provides a lot of functionality you’d rather not have to build.
          1. Agent management and reporting, including replication statistics.
          2. Displays warning, error, diagnostic information, and graphs query counts with types.
          3. Done via the “dbsmanage” host, which provides centralized shard node management as well.
        14. It’s designed with HA in mind.
          1. Each shard is two (or optionally more, I think) nodes.  We put all primary nodes in one AWS availability zone, secondaries in a different one, for protection against zone outages.
          2. Write consistency to two nodes; in other words DB transactions only complete after disk writes have completed on both nodes.  Secondary writes only require file-system (vs. MySQL) disk writes.
          3. Managed backups with configurable intervals; MySQL EC2/EBS backups aren’t trivial.
          4. Web-console based fail-over from primary to secondary; this is very helpful, particularly for maintenance purposes.
        15. Proven to work well in production, by us and others.
          1. We’ve performed 100K queries per second in load-testing, on AWS/EC2, using m1.xlarge instances.
        16. Designed with the cloud and AWS in mind, which was a great fit for us since we’re 100% in AWS.
        17. “dbsmanage” host
        18. Drivers included, of course.
          1. In addition to MyOSP, they have JDBC, PQOSP (native Postgres), ADO OSP (for .NET), and soon ODBC.
        19. Go-fish queries allow you to write standard SQL against sharded data
          1. e.g. sharded on user.id : SELECT * FROM user where FirstName=’Foo’;
            1. will return all results from all shards performing automatic aggregation
              1. sorting using a streaming map-reduce method
        20. Relatively easy to implement and go live with; took us about six weeks of hard work, deadline-looming.
        21. It’s the market-leading product, from what I can tell.
          1. 5 of the Top 50 Facebook apps in the world run dbShards.
        22. It supports sharding RDBMSs besides MySQL, including Postgres, DB2, SQL Server, MonetDb, others coming.
        23. Team : top-notch, jump-through-their-butts-for-you, good guys. 
        24. Ability to stream data to a highly performant BI backend.
      3. cons
        1. As you can see, some of these are on the pro list too, double-edged swords.
        2. Cost – it’s not free obviously, nor is it open source.
          1. Weigh the cost against market opportunity, and/or the additional headcount required to take a different approach.
        3. It’s in Java, vs. Python (snark).
        4. Doesn’t rely on MySQL replication, which has its annoyances but has been under development for a long time.
          1. Nor is there enough instrumentation around lag.  What’s needed is a programmatic way to find this out.
        5. Allows for multiple shard trees.
          1. I’m told many businesses need this as a P0, and that might be true, even for us.
          2. But I’d personally prefer to jump through fire in order to have a single shard tree, if at all possible.
            1. The complexities of multiple shard trees, particularly when it comes to HA, are too expensive to justify unless absolutely necessary, in my humble opinion.
        6. Better monitoring instrumentation is needed, ideally we’d have a programmatic way to determine various states and metrics.
        7. Command line console needs improvement, not all standard SQL is supported.
          1. That said, we’ve managed to get by with it, only occasionally using it for diagnostics.
        8. Can’t do SQL JOINs from between shard trees.  I’ve heard this is coming in a future release.
          1. This can be a real PITA, but it’s a relatively complex feature.
          2. Another reason not to have multiple shard trees, if you can avoid them.
        9. Go-fish queries are very expensive, and can slow performance to a halt, across the board.
          1. We’re currently testing a hot-fix that makes this much less severe.
          2. But slow queries can take down MySQL (e.g. thread starvation), sharding or no.
        10. HA limitations, gaps that are on their near-term roadmap, I think to be released this year:
          1. No support for eventually-consistent writes to global tables means all primaries must be available for global writes.
            1. Async, eventually consistent writes should be available as a feature in their next build, by early October.
          2. Fail-over to secondaries or back to primaries can only happen if both nodes are responding.
            1. in other words, you can’t say via the console:
              1. ‘ignore the unresponsive primary, go ahead and use the secondary’
            2. or:
              1. ‘stand me up a new EC2 instance for a secondary, in this zone/region, sync it with the existing primary, and go back into production with it’
          3. Reliable replication currently requires two nodes to be available.
            1. In other words, if a single host goes down, writes for its shard are disallowed.
              1. In the latest versions, there’s a configuration “switch” that allows for failing-down to primary
                1. But not fail down to secondary.  This is expected in an early Q4 2012 version release.
          4. dbsmanage host must be available.
            1. dbshards can run without it or a bit, but stats/alerts will be unavailable for that period.
          5. Shard 1 must be available for new auto-increment batch requests.
          6. go-fish queries depend on all primaries (or maybe all secondaries via configuration, but not some mix of the two as far as I’m aware) to be available
    2. DYI
      1. I can rattle off the names of a number of companies who have done this, and it took many months longer than our deployment of dbshards (about six weeks, largely due to the schema being largely ready for it).
      2. Given a lot of time to do it, appeals to me even now, but I still wouldn’t go this route, given the pros/cons above.
    3. The latest release of MySQL Cluster may be an option for you, it wasn’t for us back with MySQL 5.0, and not likely now, due to its limitations (e.g. no InnoDB).
    4. AWS RDS was an option for us from the onset, and I chose to manage our own instances running MySQL, before deciding how we’d shard.
      1. For the following reasons:
          2. >I wanted ownership/control around the replication stream, which RDS doesn’t allow for (last I looked) for things like:
          1. BI/reporting tools that don’t require queries to be run against secondary hosts.
            1. This hasn’t panned out as planned, but could still be implemented, and I’m happy we have this option, hope to get to it sometime soon.
          2. Asynchronous post-transaction data processing.
            1. This has worked out very well, particularly with dbshards, which allows you to build streaming plugins and do whatever you want when data changes, with that data.
              1. Event-driven model.
              2. Better for us than doing it at the app layer, which would increase latencies to our API.
        1. Concern that the critical foundational knobs and levers would be out of our reach.
          1. Can’t say for sure, but this has likely been a good choice for our particular use-case; without question we’ve been able to see and pull levers that we otherwise wouldn’t have been able to, in some cases saving our bacon.
        2. Their uptime SLAs, which hinted at unacceptable downtime for our use-case.
          1. Perhaps the biggest win on the decision not to use RDS; they’ve had a lot of down-time with this service.
        3. Ability to run tools, like mk-archiver (which we use extensively for data store size management), on a regular basis without a hitch.  Not 100% sure, but I don’t think you can do this with RDS.
        4. CloudWatch metrics/graphing is a very bad experience, and want/need better operational insights to what it provides.  Very glad we don’t depend on CW for this.
      2. All of these reasons have come at considerable cost to us as well, of course.
        1. Besides the obvious host management cycles, we have to manage :
          1. MySQL configurations, that have to map to instance sizes.
          2. Optimization and tuning of the configurations, poor-performance root-cause analysis,
          3. MySQL patches/upgrades.
          4. maybe more of the backup process than we’d like to.
          5. maybe more HA requirements than we’d like to; although I’m glad we have more control over this, per my earlier comment regarding downtime.
          6. maybe more of the storage capacity management than we’d like to.
        2. DBA headcount costs.
          1. We’ve gone through two very expensive and hard-to-find folks on this front, plus costly and often not-helpful, cycle-costing out-sourced DBA expertise.
          2. Currently getting by with a couple of experienced engineers in-house and support from CodeFutures as-needed.
      3. As I’ve seen numerous times in the past, AWS ends up building in features that fill gaps that we’ve either developed solutions for, or worked around.
        1. So if some of the RDS limitations can be worked-around, there’s a good chance that the gaps will be filled by AWS in the future.
        2. But it’s doubtful they’ll support sharding any time soon, there’s too much design and application-layer inter-dependencies involved.  Maybe I’m wrong, that’s just my humble opinion.


Posted in: API, Blog, Development, Improvements, Startups, Technology

BigDoor’s Gamification Platform Gets an Update

July 23, 2012 by

If you are a frequent reader of mygamification.com you might have noticed that a few weeks ago we quietly updated the look of the BigDoor platform here on the site. Today, we want to proudly announce the newest version of BigDoor featuring a new look, better customization and updated user notifications. With both publishers and the end-user in mind, we’ve updated the BigDoor platform with more publisher features for easier and faster implementation as well as a simple interface to improve user experience.

A few highlights on the update:

Design: With the new update comes a new slick and minimalistic module. Keeping in mind that users come to a site to engage with content, we wanted to compliment a publisher’s site, without visually over-whelming it. The persistent form factor will sit on the bottom right of the page, and won’t interfere with content or the users browsing experience. Interaction happens only when users engage or perform a rewarded action.

Customization: Gamification should be flexible enough to work for a variety of publishers and their sites. With the newest version of BigDoor, publishers can choose what features to implement (be it quests, leaderboards, rewards, etc) without the worrying about user interface. The customizable dock allows publishers to pick and choose which BigDoor powered gamification apps are visible to users, which ensures that every BigDoor gamification solution is unique.

Notifications: Included with our new design, we’ve updated our user feedback to provide users a clear notification when they have made a rewarded action. We believe that a gamification solution needs to clearly communicate to users what actions are valued. Notifications are a great way to draw the users attention to these actions and let them know that they are moving in the right direction. No longer will users be unaware when or why they have received points. This not only improves the feedback loop for the user, but increases the likelihood that users will onboard and join in.

We’re working on loading more quests, adding features and content all the time, so make sure to check back frequently and see this new version at work! If you have any questions about the new look, or would like to talk to one of our gamification experts about a BigDoor solution for your site, you can email us at info@bigdoor.com or check out our website for information about specific BigDoor features.

We’d love to hear what you think!

Posted in: BigDoor news, Blog, Game Mechanics, Gamification, Improvements, Technology, UI

BigDoor improves data monitoring with Full 360 and Vertica

May 17, 2012 by

At BigDoor, we believe firmly that a gamification solution without solid analytics and data is doomed to fail. Accurate recording of actions, points and shares ensures that users are seeing the results of their efforts, and companies are able to track and monitor the success of a BigDoor Gamified Rewards Program. Recently, our internal team headed by CTO/Co-founder Jeff Malek made some important updates to our backend databases that ensure BigDoor can handle the large number of transactions, points and data required by our clients as well as free up valuable engineering resources for the internal team.

Previously, our data came from a replicated slave of its MySQL transactional database and aggregated the results on an additional intermediary MySQL host. Following this process data was then pulled into Tableau for reporting. This custom aggregation and ETL was workable in the beginning, but as we grew along with our client base, the problems of this type of solution began to eat up engineer time and energy.

We found our solution with Full 360 and Vertica. The two companies were able to provide us a solution that was quick to implement and able to handle our complex set of data. By moving away from our custom setup, we are now able to monitor and report with much greater speed and reliability in reporting user actions.

To read more about our transition and the custom solution provided to us by Full 360 and Vertica, you can check out their case study here.

Posted in: Blog, Development, Gamification, Improvements, Loyalty, Startups, Technology

Gamifying Mygamification.com!

March 30, 2012 by

You might notice some extra stuff on mygamification.com that you haven’t seen before. That’s because mygamification.com is now using BigDoor’s Lite program to reward you for your actions on our blog. One of the biggest criticisms you’ll see about gamification focuses on how many gamification platforms do not incorporate game mechanics onto their own sites. We’ve always found this fascinating that other platforms haven’t made their programs more widely available. Our simple, lightweight implementation, the BigDoor MiniBar was available on our site.

Today we’re proud to feature the next iteration of our product, BigDoor Lite. This is one of three of our offerings that we’ll be announcing more very soon.

This program is a free, pre-designed plugin designed as a simple tool to improve loyalty, engage users and power rewards for publishers who want to see what gamification is all about. If you want more information about the program, or want to sign up, you can on www.bigdoor.com.

Earn coins for doing the things you already do:

- Checking in to our site

- Watching videos

- Liking blog posts

- Sharing links with friends via Facebook and Twitter

- Exploring MyGamification.com through Quests

You can also earn coins when your friends join the BigDoor Rewards Program from the links you share.

It’s that easy!

We’d love to hear your feedback, so feel free to leave us a comment below!

 

Posted in: Blog, Game Mechanics, Gamification, Improvements, Loyalty

Catching the “head-slappers” early

October 10, 2011 by

Software usability evaluation isn’t at all a new concept, nor is it exclusively the realm of bespectacled folks in lab coats, deftly avoiding eye contact behind one-way mirrors. Far from it – “discount” usability testing methods and tools have democratized the process nearly as much as cloud computing has done the same thing to scaling a business’s online infrastructure. (User interface evaluation is even being crowdsourced by companies like UTest.). But your fast-paced market probably demands that you be incredibly nimble and “launch first, ask questions later” – and hope your analytics, some A/B variant testing framework, and direct feedback optimize an initial design. But if you don’t take time to show really early, rough sketch stuff to potential users, “head slappers” – painfully obvious mistakes visible only once you stop protecting your early design from exposure to its intended audience – will lie in wait.

We recently tested portions of a major design update to our tools for publishers who design and deploy BigDoor’s gamification solutions to their sites. The goal? We wanted to learn if our introductory “onboarding” process demonstrated this new experience effectively enough to potential publishers to persuade them to sign up.

Findings? Nope. It did not.

But that’s really good news. Because we had several potential publishers attempt to complete this sign up process and share their frustrations/confusion, we were able to:

  • Remove jargon and update terminology that explained little
  • Identify a point where adding a couple of previews and simple callouts to explain “this does that,” and “this works like that,” makes all the difference
  • Learn that once publishers did find their way through it was fairly easy to understand how to set up the site features they wanted to use

This post should also serve as a shameless plug for Silverback, a stylish, clever tool for video recording a participant’s face and the screen they’re working on, picture-in-picture style, using a Mac laptop’s standard video camera. The impact of the results above was much easier to demonstrate to the entire company with some key video highlights, and all the raw footage was right there on my laptop to work with the moment we wrapped up testing. Hugely useful.

Some imposter dramatizes a dialog box

The barriers to quick, in-house (and crowdsourced) methods for finding out how many head-slappers your early UI designs are lower than ever before. Huge ROI for a relatively tiny investment of time and effort awaits teams of any size.

- Matt Shobe, BigDoor Chief Design Officer & early stage mistake-maker

Posted in: API, Blog, Development, Improvements, Startups, Technology, UI, UX

Wonder What We’ll Do Tomorrow?

August 26, 2011 by

Every Wednesday we have a company meeting and our awesome dev team walks us through a Demo of everything they worked on during the prior week’s sprint.  At BigDoor we iterate on our platform weekly – we listen to and value feedback from our partners and incorporate as much as we can each week to make our product that much better through each weekly iteration.  Yesterday’s demo revealed a “surprise” which one of our great devs Brian Immel details below.  We took the liberty of posting this in its entirety but feel free to check out Brian’s blog – its chock full of goodness!

“New Features…..You Didn’t Even Know About”

Yesterday’s demo was exciting.

At BigDoor, the developers (myself included) Demo to the entire company everything we worked on during last week’s sprint. Honestly it’s one of my favorite parts of the job. We move so fast that the demo has become a greatest hits list of killer features that makes our platform so great. With so many awesome things coming down the pipe weekly, we set the bar pretty high. So to demo something truly impressive it’s got to break the mold of normal awesome and become uber-awesome.

During yesterday’s Demo, our fellow developer, Harley Holt gave us that opportunity.

Our weekly sprints are jammed packed with “stories” we’re working on. Usually this means new features, performance gains and bug fixes that are in line with our company roadmap.

However, Harley went above and beyond the call of duty. Somewhere between his daily work hours and getting a nasty ankle sprain playing kickball, he built something truly uber awesome. I can’t tell you what right now (awwww, you tease), but I will say it got me all giddy and giggly with excitement.

As a result, today’s demo was exceptional. At the end of our normal routine, Harley showed off the thing he’s been working on for the last few weeks outside of our normal sprints. No one asked him to do it. It was just a damn good idea so he led himself.

So kudos to the man. In my mind it was worth the ankle sprain, since we’ll see ripples from Harley’s work for months to come.

And that was all before 10:30 a.m. Wednesday. Wonder what we’ll do tomorrow?

Posted in: Blog, Development, Gamification, Improvements, Startups, Success, Technology

Slaying Database Monsters

March 23, 2011 by

Recently we were happy to post some shout outs for our dev team, who executed a significant upgrade to our systems with minimal disruption. A flawless transition to keep things performing at the levels we expect. But how does the API usually perform? We wanted to share some stats regarding how quickly our API typically responds. Below are some external, minute-by-minute checks of our API from a diverse set of US locations. The following was taken over the course of a 24-hour period:

Average GET requests: Under 175 milliseconds
Average Leaderboard requests: Under 250 milliseconds
Average transaction POST: Under 400 milliseconds

By way of comparison, Facebook’s average API response time for us over the course of the last month has been 14,249 milliseconds.

The key takeaway here is: “Our tech boys rock” but in more technical terms: “We slayed the evil database monster with some crazy ass ops wizardry.”

Posted in: API, Blog, Improvements, Technology

Level Up: The CityVille Challenge

January 14, 2011 by

Earlier this week during our weekly demo a conversation came up about intuitiveness and play, specifically how much CityVille nails it on every level. For those who don’t already know, CityVille is the hugely popular game that allows users to build their own custom city. The game launched a little over a month and just announced more than 100 million active users.

The game is simple, intuitive and encourages people to share and build their city so effortlessly that it’s addictive. Zynga’s CTO recently said, “The company’s ‘secret sauce’ lies in taking mechanics and themes from the gaming industry and making them simple, social and easy to learn.”

The BigDoor team began talking about how much we admire CityVille’s incredibly fun and easy game mechanics and how we’d like to emulate those same mechanics across the BigDoor API. We’re constantly iterating on our platform; we have weekly sprints in which we prioritize feedback from our partners and make upgrades to our tool set.

We can truly aspire to create something as great as CityVille. Their  numbers are astounding and really show the opportunity that lies in truly great game mechanics and social gaming! So the team was challenged with two things: continue working to create an intuitive, fun and simple user experience for the BigDoor API, and get to Level 10 in CityVille.

The challenge has been thrown down, now what Level are you?

Posted in: API, Blog, Game Mechanics, Gamification, Gaming, Improvements, UI, User engagement