Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am trying build a social media site, but I need a hands on senior engineer/architect to guide and assist me in the server-side development since I am a rookie.

Technology (which I am familliar with) to be used includes Java, JAX-RS, Spring and Hibernate. Unfortunately, I dont know what other technology skills an engineer/architect should have besides those mentioned above?

The SNS I am trying to build is like Facebook which can guide you in terms of features and functionalities.

share|improve this question

migrated from stackoverflow.com May 4 '11 at 8:18

This question came from our site for professional and enthusiast programmers.

closed as not a real question by Thomas Owens Mar 19 '12 at 21:17

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Katie, how many users do you need to serve concurrently? This is key question when you choose the technology. Also, if you are somewhat familiar with Spring-Hibernate, then maybe you should just try to build a prototype and come back here with more concrete questions. Good luck! –  bpgergo May 4 '11 at 8:17
My guess is you are looking for someone willing to take a risk who is will to work for shares rather than hard cash, so don't be too picky. ;) Note: I am pretty sure Facebook doesn't uses any of these technologies. Don't tie yourself to a specific technology, just work on making a site people will want to use. –  Peter Lawrey May 4 '11 at 8:20
@bpgergo To start i want to serve about 10,000 people first then i will expand... –  katie May 4 '11 at 8:37
I've made some edits to make the question a little more likely to garner some answers –  Gary Rowe May 4 '11 at 12:34
Remember that it's OK to start small with an easy to build application suitable for a few hundred users. Then, once your site is doing well and you've got funding for the next growth spurt, throw out the old code and start all over again using technologies that are suitable for your new level of scale and where you want to go next. Migrate your data as necessary. Rinse and repeat as you grow. –  Gary Rowe May 4 '11 at 12:39

3 Answers 3

up vote 5 down vote accepted

Start with a small prototype that is hosted on a cloud provider (IAAS if you're confident with your system administrator skills, else a PAAS provider). Having lots of users 'Is a nice problem to have', but don't optimize for it too early, you might be surprised where your scale pain points are and where they aren't.

If you're using the Java stack I recommend using JMeter and some BDD/ATDD style tests to hammer your proof of concept to see where the scale pain points might be.

I'd be a little more flexible in your technology choices, you're restricting yourself to what you currently know (and trust me, Hibernate or any other ORM is going to slow you down at a large scale). It's Horses for courses and some of what you list above may not be appropriate further down the road.

You need an engineer that is familiar with distributed and messaging architectures who also knows about multi-threaded/concurrent development programming paradigms. It also sounds like you'll need an engineer who rally understands web protocols and how to design a web based solution that is efficient and well balanced between client and server.

These types of engineers are very hard to find (you only have to look at Google et al battling over hiring them). So you might find that you're going to have to learn about a lot of this yourself, but that's all part of the fun right! :D

share|improve this answer
very good answer +1 for " I'd be a little more flexible in your technology choices " Requirement shud dictate choice of technology. And also it is really fun to solve the kind of problems mentioned in the OP. –  Wildling May 4 '11 at 12:53
+1 for "you're going to have to learn about a lot of this yourself, but that's all part of the fun". –  user8685 May 4 '11 at 14:09

let me put it in the most simplest form:

"Don't Scale until you fail"

Think about KISS and YAGNI. When you start serving more than your current system can sustain that's when you re-scale, not before.

share|improve this answer
+1: First. Build something that works. Then, as you start to grow, you'll simply rebuild to scale. As technology ages and changes you'll be constantly rebuilding anyway. Until you have enough users to worry about scalability, don't worry about scalability. Get users first. –  S.Lott May 4 '11 at 9:54
So you suggest just painting until you reach the corner? –  user1249 May 4 '11 at 10:01
@Anderson why dont you elaborate ? tell us what you think is wrong ? i ask because you are one of very few ppl who disagree on this –  Wildling May 4 '11 at 12:55

To play devil's advocate, and to voice the lingering concerns I and others might have with some of the other answers, I would say:

"Scale BEFORE you fail

...but not too much before"

When a website is starting out, it is critical that users do not experience any negative experiences from a serious technical failure. The first 1000 users can be the hardest to get, but if your site is down for a couple days (especially a social networking site) you will be bleeding users at an alarming rate. Failure is not really an option. That being said, slowdowns and the like are not a death sentence, so I would say build things the best you can with the technologies you are most comfortable with at first, but when you see things start to spike, aggressively seek an engineer that really has some experience with this kind of thing. Use whatever technology they choose, and learn it the best you can. If things really explode, you probably will not be writing a whole lot of code anyway.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.