views:

233

answers:

9

Here are the estimates the system should handle:

  • 3000+ end users
  • 150+ offices around the world
  • 1500+ concurrent users at peak times
  • 10.000+ daily updates
  • 4-5 commits per second
  • 50-70 transactions per second (reads/searches/updates)

This will be internal only business application, dedicated to help shipping company with worldwide shipment management.

What would be your technology choice, why that choice and roughly how long would it take to implement it? Thanks.

Note: I'm not recruiting. :-)

A: 

Your daily update numbers vs commits do not add up. Four commits per second = 14,400 per hour.

You did not mention anything about expected database size.

In any case, I would concentrate my efforts on choosing a robust back end like Oracle, Sybase, MS etc. This choice will make the most difference in performance. The front end could either be a desktop app or WEB app depending on needs. Since this will be used in many offices around the world, a WEB app might make the most sense.

+2  A: 

wikipedia manages much more demanding requirements with MySQL

howlingmadhowie
Examples are a good method for comparison. =]
strager
Wikipedia handles demanding requirements with a complex setup: http://meta.wikimedia.org/wiki/Wikimedia_servers.
nes1983
A: 

I'd go with MySQL or PostgreSQL. Not likely to have problems with either one for your requirements.

GeoffreyF67
+2  A: 

Your volumes are significant but not likely to strain any credible RDBMS if programmed efficiently. If your team is sloppy (i.e., casually putting SQL queries directly into components which are then composed into larger components), you face the likelihood of a "multiplier" effect where one logical requirement (get the data necessary for this page) turns into a high number of physical database queries.

So, rather than focussing on the capacity of your RDBMS, you should focus on the capacity of your programmers and the degree to which your implementation language and environment facilitate profiling and refactoring.

The scenario you propose is clearly a 24x7x365 one, too, so you should also consider the need for monitoring / dashboard requirements.

There's no way to estimate development effort based on the needs you've presented; it's great that you've analyzed your transactions to this level of granularity, but the main determinant of development effort will be the domain and UI requirements.

Larry OBrien
A: 

with my limited knowledge of web development (which is clearly what you will need), I'd choose google widget toolkit with java backend. i have experience with mysql,and i bet that will suit your database needs.

rhapsodhy
A: 

I love object-databases. In terms of commits-per-second and database-roundtrip, no relational database can hold up. Check out db4o. It's dead easy to learn, check out the examples!

As for the programming language and UI framework: Well, take what your team is good at. Dynamic languages with fewer meta-time wasting will probably save time.

nes1983
A: 

There is not enough information provided here to give a proper recommendation. A little more due diligence is in order.

  • What is the IT culture like? Do they prefer lots of little servers or fewer bigger servers or big iron? What is their position on virtualization?
  • What is the corporate culture like? What is the political climate like? The open source offerings may very well handle the load but you may need to go with a proprietary vendor just because they are already used to navigating the political winds of a large company. Perception is important.
  • What is the maturity level of the organization? Do they already have an Enterprise Architecture team in place? Do they even know what EA is?
  • You've described the operational side but what about the analytical side? What OLAP technology are they expecting to use or already have in place?
  • Speaking of integration, what other systems will you need to integrate with?
Glenn
+2  A: 

So, you asked how I would tackle such a project. In the Smalltalk world, people seem to agree that Gemstone makes things scale somewhat magically.

So, what I'd really do is this: I'd start developing in a simple Squeak image, using SandstoneDB. Then, this moment would come where a single image begins being too slow.

GemStone then takes care of copying your public objects (those visible from a certain root) back and forth between all instances. You get sessions and enhanced query functionalities, plus quite a fast VM.

It shares data with C, Java and Ruby.

In fact, they have their own VM for ruby, which is also worth a look.

nes1983
+1  A: 

Choose the technology your developers know and are familiar with. All major technologies out there will handle such requirements with ease.

Drejc