
How I built an app with 500,000 users in 5 days on a $100 server - kiyanwang
https://medium.com/unboxd/how-i-built-an-app-with-500-000-users-in-5-days-on-a-100-server-77deeb238e83#.g8ipvn23a
======
joshstrange
This article left a really bad taste in my mouth. I don't believe GoSnaps ==
GoChat in terms of complexity and the constant back patting and self
congratulating is really distracting. There were a couple of decent takeaways
but largely the whole post revolved around how "How smart am I?" and "What
great foresight I have".

I really don't approve at all of the GoChat shaming going on. The author may
be 100% correct that GoChat made mistakes in writing code that doesn't scale
well but that doesn't give him a blank check to beat and berate GoChat. It
reads as a very discouraging post to newer/less experienced programmers in my
opinion, essentially "Don't even bother making something unless you know it
can scale to millions of users" which I think is a terrible message to be
sending.

~~~
homero
Yeah it's complete bs. I've worked on chat before and even 100 clients destroy
a core or even two.

Now I would use pusher but that's extremely expensive but scalable.

~~~
angersock
Yeah, no, that's wrong.

If you have problems with this, there's something really wrong with either
your design or your choice of tools.

How'd you go about building this?

~~~
homero
In 2008 with php and ajax

------
zongitsrinzler
The real takeaway from this is that the author uses Hackathon Starter
([https://github.com/sahat/hackathon-
starter](https://github.com/sahat/hackathon-starter)).

I have used it for multiple projects and it gives a huge head start compared
to starting from zero. Signing up, logging in, resetting the password,
uploading, etc all seem like easy work but when you pile them all up you can
easily spend a week just getting to the point where you are within minutes of
cloning the starter repository.

However the failure of GoChat is not relevant to Pokemon Go. While GoChat
might have done something very wrong comparing 1mil users to an app with tens
of millions of concurrent users is invalid. Pokemon Go would be a NoGo running
on a single Node.js machine without any sort of balancing.

~~~
Mithaldu
> However the failure of GoChat is not relevant to Pokemon Go.

That part is almost right, but also a little confused.

He built GoSnaps, which is a geo-enabled gallery with: No chat, few messages,
few writers, many readers, medium amount of reads, large messages, not time-
dependent. (Not even user state.)

Then he contrasts that to the failure of GoChat, which is a geo-enabled chat
with: Many-to-many chat, many messages, many writers, many readers, many read
operations, small messages, very time-dependent.

The performance profile between these two things is wildly different and the
way he's patting himself on the back over what amounts to half knowledge is
pretty disgusting.

~~~
jonzathe
Failure of GoChat? GoChat didn't fail, it just had some hurdles it needed to
jump. GoChat is back up 100% baby! (I'm the guy who started GoChat). I reached
out to the author of this story and he has since updated his story. I now have
a team of 6 dedicated guys helping me full time on this and we're cruising
forward.

~~~
Mithaldu
That is great to hear. Good work! Sorry i can't edit the post anymore,
otherwise i'd update that. :)

Edit: Wow, he did update it and he's only defending his bullshit with more
half-knowledge. At this point i'm ready to call him a liar, just over this
claim: "My conclusion is that both apps are very similar in terms of
scalability complexity."

------
mootothemax
Ah, the good old "I could build StackOverflow in a weekend" line of thinking -
I'm sure we've all been there.

There's a world of difference in building a photo sharing app with XXX,XXX
users vs. building a chat app with XXX,XXX users.

When you do anything that involves chat or that level of concurrency,
surprises will bite you in the behind, multiple times, even if you desperately
try to use as much existing software as possible.

(as anyone who's taken a look at ejabberd, thought it'll play nicely, and then
load tested their code will tell you)

Frankly, PHP vs. Rails vs. Node[1] vs .Net vs Java will be the least of your
troubles.

[1] I do fear that the author is going to find a nasty surprise or two for
themself regarding Node's performance issues

~~~
manmal
Though, using a specialized language like Erlang can make it possible to run
WhatsApp on only 50 engineers (in 2015). I agree with the OP that choosing a
stack like Rails can kill your Pokemon Go related MVP pretty quickly (I'm a
huge Rails fan myself, but would definitely use Node.js for something like
that).

~~~
Mahn
> make it possible to run WhatsApp on only 50 engineers

Frankly, I'm sure Erlang is great, but with 50 full time skilled engineers I'm
pretty sure you could run WhatsApp on almost anything.

~~~
im_down_w_otp
The largest explosion in their user base came when I think they were at
something like ~11 engineers, and from what I've heard the largest additions
to their engineering team came on the frontend side, not the backend.

------
jbardnz
First I would say Pokemon Go has done incredibly well to handle such massive
growth so quickly, no doubt they were able to leverage a lot from Ingress but
I could imagine many other companies having days of downtime while trying to
scale up so quickly.

I also tend to disagree a bit with the article. For every situation like this
were early scalability is important their are a 1000 MVP apps that are
prematurely optimized or over engineered. At the end of the day the chance of
anyone building an app that will get over 100,000+ in a week (and keep those
users coming back) is very very very slim.

~~~
drinchev
100% agree with you. As a freelancer I usually have to decide technology stack
and infrastructure and I always go with the cheapest option for my client with
the argument that one day he could just scale it up even by rewriting it.

This makes 3 months project delivered in 1 month and in the end the client
usually benefits that.

~~~
huskyr
> I always go with the cheapest option for my client

> with the argument that one day he could just scale

> it up even by rewriting it.

Which in practice of course never happens. Instead, the old code gets patched
up until everything fails completely, and only then a rewrite happens :)

~~~
kevan
Which is a perfectly valid choice in many cases. I plan to drive my car for as
long as possible and into the ground before I get another one. As long as I
know the eventual replacement cost is coming and budget for it it can be a
good choice.

------
gedrap
>>> Where would I have put my images? In the database: MongoDB. It would
require no configuration and almost no code.

Why... would anyone actually do that in anything more than a classroom example
for an application like the one described? Amazon S3 and similar services have
very decent libraries for pretty much every popular programming language, why
would you re-implement that?

>>> MVP and scalability can coexist

I'd replace that with less catchy but probably more correct 'experienced devs
can make more scalable mvps with little extra cost, if any'. MVP doesn't mean
lets just go silly and make the quickest and dirtiest decision imaginable.

It's a matter of experience to recognize potential problems and the respective
potential solutions, and program accordingly. SQL schema is a pretty good
example. Often it makes a big difference in scaling and often you can design
the initial schema to be much more scalable with some experience and a few
moments of planning.

~~~
jjnoakes
The author says in the article that putting images in the database is not what
he did.

~~~
asadjb
I think the point the parent is trying to make is that no one would do that
anyway, and mentioning it in the article as something that makes your
application slow is pointless.

~~~
jjnoakes
But the article mentions he used Google's cloud, and the OP asked "Why would
anyone reimplement AWS?"

It sure seemed like the OP skimmed the article, found something out of
context, and refuted it here.

~~~
gedrap
Nope, I read it. Maybe just didn't explain my point clearly enough.

He mentioned that he is using Google Cloud instead of storing images in
MongoDB and my question was what's the big deal about it? It doesn't seem like
something you'd do to make it more scalable, it's something you'd do anyway.

~~~
jjnoakes
I've seen plenty of people suggest or question which is better, storing files
in a database or outside of a database.

Like just about everything, each has trade-offs.

I don't find it immediately obvious that a database would never be used for
such a thing, or that reaching for a third party file storage service is the
only solution to consider.

------
0xmohit
> If I would have built GoSnaps with a slower programming language or with a
> big framework, I would have required more servers. If I would have used
> something like PHP with Symfony, or Python with Django, or Ruby on Rails, I
> would have been spending my days on fixing slow parts of the app now, or
> adding servers. Trust me, I’ve done it many times before.

> As said, GoSnaps uses NodeJS as the backend language/platform, which is
> generally fast and efficient. I use Mongoose as an ORM to make the MongoDB
> work straightforward as a programmer.

~~~
nathan_f77
I was skeptical too, but the guy has 500,000 users on a $100/mo server. It's
not even up for debate anymore, Node.js is fast and scalable. You might not
like MongoDB, but it also works.

~~~
Mithaldu
The performance profile matters. 500000 users on an instagram type site create
a COMPLETELY different kind of load compared to 500000 on a geo-enabled
realtime many-to-many chat program.

------
agentultra
There's a little too much self-congratulatory prose in here. And poor advice (
_Use NodeJS because its fast_ ).

But there is one take-away at least... design your application around your
data and how your users will interact with it and performance will generally
fall out of that. And it doesn't take much to start that way rather than
leaving it as an after-thought.

People might break out the (oft-misquoted) "premature-optimization" horse for
a little beating, but performance _does_ matter. At least the bounds matter
for most applications. You might not need to eek out every cache line but you
can set targets up-front to say, "We cannot tolerate more than Xms req-to-res
time" and bake that into your design.

~~~
tracker1
It's funny you mention node as poor advice... and while I think it would need
be replaced at scale, I tend to reach for node first, if only because it's
easy enough to prototype something that can scale out, and gets decent per-
instance performance. In this case, I'd probably have started with go for the
core chat engine, combined with a plan to shard/distribute chat channels,
however you want to break them up.

As for pre-mature optimization, for something like this, they should have had
a plan to grow, and enough base to be able to handle some early growth. I
think falling over once you hit a million or more simultaneous users can
happen in a lot of ways. Especially if growth happens faster than you can
provision servers/funds.

~~~
agentultra
You can write a fast server in Python 3 that can benchmark well against Node
[0].

The author tried to sell us on the idea that Python is slow because Django is
slow and you shouldn't use Ruby because Rails is slow. You should just use
Node because its fast.

Well I don't know about you but I've seen slow Node applications too.

It all comes down to data. If you really want to maintain your performance
goals you have to include them in your design. You have to design for your
data. Show me your data and I can write the program. Design it well and you
can scale up when the time comes with minimal effort.

Besides there are other factors to consider such as familiarity with the
tools, correctness of the implementation, etc. Javascript is great and all but
it is incredibly easy to make errors that will go unnoticed until it hits
production. The law of large numbers won't protect you if you're used to the
blanket of obscurity. And so I find you need many more layers of tooling and
choose your subset of the language carefully to maximize its use... something
that you don't have to do as much with OCaml or Haskell for instance.

Hence, "just use Node because its fast," is misguided at best. (And I'm not
even a Node hater.. I maintain a number of Node applications presently).

[0] [http://magic.io/blog/uvloop-blazing-fast-python-
networking/](http://magic.io/blog/uvloop-blazing-fast-python-networking/)

~~~
tracker1
Agreed, the reasoning isn't sound... I was just meaning that node is a
perfectly serviceable platform, and better than most by design. I've also seen
some hideous node apps... generally because people don't really get how it
works, and try to do heavy math in the main process.

------
tie_
Survivorship bias anyone?

How many times did a project fail, because it the non-aspects (e.g.
scalability) were undernegineered? How many times did it fail because it
couldn't ship on time/budget due to excessive engineering? We do not normally
read such stories, because they are totally unexciting, taken separately. And
one failed case of GoChat does not a worthy stat make.

Ultimately, good job to the guy for nailing a sweet spot between his skills
and the market of the application created by those skills. Just do not assume
that's everybody's sweet spot.

------
RubyPinch
> But this would have been totally disastrous under any type of serious load.
> Even if I would have simplified the above query to only include three
> conditions/sorting operations, it would have been disastrous. Why? Because
> this is not how a database is supposed to be used. A database should query
> only on one index at a time, which is impossible with these geospatial
> queries.

> On the database side, I separate the snaps into a few different collections:
> all snaps, most liked snaps, newest snaps, newest valid snaps and so forth.

Pardon my ignorance, but don't most databases have some method of handling
these issues?

(defining multiple indexes for use, having support for geospatial data, having
support for like, subsections of the existing dataset, etc?)

I thought that the main goal was to offload the developer's code's logic onto
the performant database, as opposed to offloading the database's logic and
caching onto the developer's code? is the former not practical?

~~~
bontoJR
Yes, with Postgres (which I am most confident to talk about), most precisely
using PostGIS, you can do that in a matter of hours using it for geo-queries
and indexing for getting important stuff (new, trending, etc...). Plus
Postgres is supported basically everywhere in any tech stack. I still don't
get one point, why people totally ignore SQL dbs by default with new products?
I know MongoBD, RethinkDB, CouchDB, etc... are really fascinating solutions,
but why not considering SQL eliminating it by default? I am just curios.

~~~
spion
I think its because the only really viable scaling option for Postgres is
vertical scaling. Even just setting up any sort of replication with automatic
failover is still a pain (multimaster is not yet built in, master-slave also
needs 3rd party failover program...)

~~~
gglitch
So, how large would his application have to get before that became a problem?

~~~
spion
Replication with automatic failover? I'd go for it immediately, unless you are
okay with long downtime and some data loss in case the server goes down.

But if you can live with that, then yes, you're unlikely to have actual
_scaling_ problems - at least not for projects like the OP.

------
CarolineW
The two previous submissions have a few comments scattered between them - here
are direct links to those comments:

[https://news.ycombinator.com/item?id=12122681](https://news.ycombinator.com/item?id=12122681)

[https://news.ycombinator.com/item?id=12132605](https://news.ycombinator.com/item?id=12132605)

[https://news.ycombinator.com/item?id=12132610](https://news.ycombinator.com/item?id=12132610)

Despite getting a few votes, neither of those submissions got any real
attention first time round - no doubt pure chance that this one has got enough
attention to hit the front page.

------
allendoerfer
I read the story a while ago and was waiting for the criticism in the
comments. Now one comment [0] already pointed out many of the issues of the
article.

What's been mentioned in other comments but not explained in great detail is
the database design, so I want to expand that:

The right way (TM) to do databases is to design a solid schema to keep data
integrity and then apply indices and caches depending on your application
needs. To be honest his application seems super simple to cache top-down, so a
few lines inside the nginx config (which seems to scare him for some reason)
would probably do. But if you use a real database (also TM) you can go bottom
up, too:

1\. solid schema with constraints

2\. indices depending on your application

3\. stored procedures, database views

4\. some non-relational cache like MongoDB to cache denormalized data

5\. maybe something in memory

6\. (application)

7\. nginx caching

He started with 4. What he did is not a solid database design to brag about,
instead he hardcoded a cache inside his application. If he wants to scale his
application vertically or horizontally he will have big problems, because he
misses a point at the beginning which contains the truth on which everything
else is build upon. If he starts scaling up and then wants to change his
schema he is basically in hell.

What he did is nothing bad. It is exactly "the MVP way". MVP is not about slow
or buggy software but a really small feature set and applying YAGNI. MVP is
nothing bad, he seems to have great sucess with it! What I am criticising is
not how he build his software but what he wrote about it, comparing it to a
much harder case and thinking it has something to do with good design.

[0]:
[https://news.ycombinator.com/item?id=12135748](https://news.ycombinator.com/item?id=12135748)

------
roddux
>If I would have used something [..] _Python with Django_ [..] I would have
been spending my days on fixing slow parts of the app

>GoSnaps uses NodeJS as the backend language/platform

Is NodeJS really that much faster than Python in practise-- even with a fast
framework (Falcon, pycnic, hug.rest) and Pypy? I know a lot of work has been
put into making V8 fast but I didn't realise it was notably faster than
Python.

~~~
csl
To me it seems like he's talking about plain _CPython_ , which isn't even in
the same class as Node.js/V8. As you mention, the correct comparison would be
against PyPy.

------
iamleppert
You could have built most of the data side entirely static. First convert the
user coordinates to simple mercator XY. Just divide or round that down to some
precision and put the resources in a namespaced S3 bucket/path. Then just do a
directory listing on resources in that bucket. You could even name them the
full precision xy coord so you could still sort by distance, within the
bucket.

Let S3 be your database.

You don’t need the full precision of a geospatial query or database if you’re
building a simple app that organizes content by location. Depending on your
density you segment few 100 meters or few 1000 meters.

~~~
tracker1
Thank you... was my thought for channels as well, geohashes of varying
precision for chat channels, and for more static resources using something
like you suggest.

------
arviewer
This reminds me of a quote from Biz Stone, Twitter founder: It takes ten years
to become an overnight success.

[https://twitter.com/liftapp/status/472080510546903040](https://twitter.com/liftapp/status/472080510546903040)

------
maxencecornet
>GoSnaps grew to 60k users its first day, 160k users on its second day and
500k unique users after 5 days (which is now)

How did you market the app ?

~~~
malinens
No need to market. In most countries Pokemon Go was already popular but app
was not officially available in Play Store/App Store yet. So millions of
people searched stores for Pokemon Go and downloaded chat, tutorial and apps
like GoSnaps instead..

~~~
10dpd
So your initial user growth was from people who weren't actually able to
contribute to the app?

~~~
Sarang235
There are apks avaialable outside of app store and here in my office in India
almost all of my colleagues are onto capturing pokemons

------
zuck9
Reading this leaves me doubtful whether to use MongoDB or not again:

[https://www.google.com/search?q=dont+use+mongodb](https://www.google.com/search?q=dont+use+mongodb)

[https://www.reddit.com/r/programming/comments/3dvzsl/why_you...](https://www.reddit.com/r/programming/comments/3dvzsl/why_you_should_never_ever_ever_use_mongodb/)

Do people at big startups use MongoDB in production?

~~~
vishbar
This seems more like a limited-lifetime side project rather than an actual
viable startup. I've used MongoDB for situations like this where I just need
to stuff some simple data into a datastore and retrieve it later without any
particularly complicated queries.

Personally, if I were the author, I'd switch over to PostgreSQL the second I
start worrying about more complex queries, though.

------
Veratyr
Surprised he didn't talk about dedicated/colocated servers. For $100/month he
could have had a E3-1231v3, 32GB of RAM, 2x480GB SSDs and unmetered gigabit
bandwidth from OVH.

Instead he paid $100 for 4 hyperthreads, 15GB of RAM, a few GB of storage and
fast but horrendously expensive bandwidth (assuming he used the n1-standard-4,
which matches his description).

If he'd set it up to scale the number of servers with load or something it'd
make sense but this doesn't make any at all.

------
adeptus
Pff that's nothing. I could build a fake app, in less than 1 hour, for $100
and get about 5 million downloads in 1 day.

Step 1. Find some opensource app code

Step 2. Call it Pokemon Go 2!

Step 3. Upload it to Appstore & link it to dropbox

Step 4. Spend $100 on African "talent" to give fake 5 star reviews & positive
comments in app store.

Step 5. Hit F5 repeatedly at Appstore to watch the download counter increase
to 5 million in 24 hours.

Step 6. Profit ?!?!

Step 7. Post story in /r/nosleep because too much guilt fooling 5 Million
people.

~~~
vblord
Yeah, if you go to the play store and search for pokemon go you get hundreds
of people making spin of type things and guides. Reminds me of ambulance
chasers and art van salesmen. Just knowing that they make tons of money off
their overnight app and I make s __t off an app I spent a lot of time on is
discouraging.

------
kimshibal
Our company migrated to elixir 2 months ago. We have 2M users per server at
$20/month.

~~~
scotu
I would be interested in more info about what kind of product you are working
on in elixir. Is it chat-related or not at all?

------
stonewhite
I just don't get how he goes on and on about uploading images to cloud storage
instead of mongodb, which he makes it sound like a very genuine decision.

Is it just me or what he telling is rudimentary?

~~~
corobo
I'm fairly sure that was the first think I learned after the basics on how to
connect, create, read, update, delete

"Don't store images in the database. No, not even then."

------
ekiara
In both cases the developers have committed to a pretty big monthly payment
for an app that serves hundreds of thousands of users.

4000USD is a huge amount and even 100USD monthly is a lot to spend out of
pocket without a plan to recover that money. Do they have any plan of making
money out of these sites or are they purely CV/portfolio pieces?

------
bojo
I'm less interested about the technology and more interested in whether he has
a plan for monetizing all those users.

------
tckr
… and earned $0.

~~~
nathan_f77
Yeah, although building something with 500,000 users gets you a lot of
attention, and probably a lot of free marketing for his actual startup.

------
jackweirdy
The idea of putting into different collections up front is pretty smart. To
generalise it into a broader lesson, I guess you could say it makes sense to
make a one-time effort up front to save complexity down the line.

------
cocktailpeanuts
It is true that GoChat doesn't need to be that expensive to maintain and his
analysis is pretty much correct (I've maintained something that had similar
amount of traffic, similar dynamics, and didn't cost me arms and legs at all,
far from it. It's amazing how cheap you can start a company nowadays)

But no need for bashing someone else. These things are a fad so this GoSnaps
thing will probably go the same way as GoChat anyway.

------
kriro
Solid read, good basic thinking with regards to scalability via basically
prefiltering data except for the one query you need to run at runtime.

It's a bit strange that the author mentions Scala as lean/fast with lots of
libraries (along with JS and Go) but Java is too bulky. I'd say modern Java 8
can be used in a pretty lean manner. There's also nice and small web
frameworks (Spark etc.).

------
webtechgal
Here is my take on this:

1\. MVP vs. scalability: While building scalable product/s right from the MVP
stage is generally a good idea, it may not be particularly beneficial or
applicable to most scenarios. I mean

a) how many typical startups happen to scale to 500k or 1M users within days
from launch?

b) most founders would be needing an MVP mainly for market validation, as a
proof-of-concept and for the purpose of attracting seed/startup funding

c) many founders - especially non-coders - may not have the luxury/resources
to have scalability built in to the MVP

2\. The original story goes to reconfirm my belief, based on multiple past
experiences going back many years, that database continues to remain a (huge)
bottleneck for web apps with high traffic volumes and max possible database
optimization (right from config tune-up to table structure
design/normalization to query optimization) can pay huge dividends in most
cases.

------
nickpsecurity
There's a lot of flak over poor comparison to photos and self-promotion.
However, his overall point is still true: just putting a little effort in
upfront with assumption you will succeed can prevent these problems. My
baseline for evaluating this is "Did they do at least as well as someone who
spent 30 seconds on Google?" Short version: doing better wouldn't have
required a ton of thinking.

Here's what 30 seconds Googling "highly-scalable chat architecture" gave me:

[http://highscalability.com/blog/2014/10/13/how-league-of-
leg...](http://highscalability.com/blog/2014/10/13/how-league-of-legends-
scaled-chat-to-70-million-players-it-t.html)

[https://engineering.riotgames.com/news/chat-service-
architec...](https://engineering.riotgames.com/news/chat-service-architecture-
servers)

[http://doc.akka.io/docs/akka/1.3.1/scala/tutorial-chat-
serve...](http://doc.akka.io/docs/akka/1.3.1/scala/tutorial-chat-server.html)

Note: Like to have seen numbers for field-test of the above in the article.
Yet, it would've gotten someone thinking.

[http://lsirpeople.epfl.ch/nbonvin/dl.php?f=chat-
report.pdf](http://lsirpeople.epfl.ch/nbonvin/dl.php?f=chat-report.pdf)

[http://doc.utwente.nl/68325/1/imp-
pasm.pdf](http://doc.utwente.nl/68325/1/imp-pasm.pdf)

Previous times doing this for web services led me to highscalability.com with
many architectures to imitate with fairly mature software components
available. At this point, the common ones should practically have templates
for "enter metrics expected here" then click to deploy.

------
nathan_f77
If anyone has more tips about how to get 500,000 users in 5 days, I'm sure we
would all like to hear them.

~~~
codingdave
Attach yourself to something viral...

Of course, getting 500,000 users is nowhere near the same thing as keeping
500,000 users.

~~~
nathan_f77
Actually not bad advice. Don't try to create the waves, ride the waves.

------
antoineMoPa
For me, this article is very reassuring.

My server used to be at <0.8% cpu usage. Now that I installed mongodb with
almost nobody using my app (< 2 person per hour), my cpu is always at ~1.6%
(It doubled because of mongodb!). At first, I feared that my cpu use would be
enormous as soon as I would get new users. Now I guess my cpu% increase is due
to some overhead that will not grow too much with db size/use (if the author
was able to make an app of this scale with mongodb). I'll also try the lean()
mongoose thing.

------
CameronBanga
I'm all for critiques of software and how to improve work, but do we need to
rag on the guy who made GoChat? Looking at the project, it was clear it was a
single guy or a couple people, working to put out a project for experience.

It's poor form to self-aggrandize and say "move fast, make MVPs, etc", and
then write a post pointing out over and over how people messed up, when they
were trying to move fast and make an MVP.

------
projectramo
Everyone is talking about the technical feat, but the real insight for me is
that you should hitch your wagon to a rocket ship.

Pokemon is a rocket ship right now, and any new app has this enormous exposure
advantage.

It is also important that it scale well or else you'll squander your
advantage.

For what it is worth, I was very impressed by the technical stuff. (It is
making me laugh to read about how disappointed others are. I feel like I
missed something.)

~~~
stevenwiles
This is the only real takeaway here, as far as I can see - If you build an app
that attempts to associate itself with another extremely popular app, then
your app will probably be a little popular too.

This is nothing new or insightful, but the author sure found a way to make
himself feel good about it.

------
andy_ppp
I'm going to use Cassandra for part of my application - the bit that might
conceivably be unperformant and very difficult to cache - even though it'll
take a few extra days now to get working over using Postgres I'd rather just
do this at the start than have migrate a write heavy and main part of the apps
functionality while live.

~~~
tracker1
Most cloud providers have a BigTable solution already, though not the same as
C*, would leave you to build the app over provisioning/configuring a cassandra
cluster.

Depends on your application of course, but if you're self-indexing anyway, may
as well lean on your environment (given a proper backup/exit strategy).

~~~
andy_ppp
You are spot on here actually - I'm using AWS might as well go to the original
dynamo db then.

[https://aws.amazon.com/dynamodb/](https://aws.amazon.com/dynamodb/)

------
mijoharas
> I personally love Erlang and would never use it for an MVP, so all your
> arguments are invalid.

Could anyone elaborate on the point the author was trying to make here? is it
that erlang doesn't have many pre-existing libraries (for building an MVP) or
is not fast enough (or something else)?

~~~
sbalea
In all likelihood it is about the relatively lesser abundance of high quality,
ready to use building block in the Erlang/Elixir ecosystem vs NodeJS or RoR.
In my opinion, Node and its associated ecosystem will get you to your MVP
faster, but Erlang/Elixir will provide you with a more solid base to build and
scale a commercial application of this kind, it's what they've been designed
to do.

------
EGreg
The more interesting question is how did these apps get their users in the
first place?

------
ryanbertrand
Great job! One thing I noticed is your app requests my location always (even
when the app is not on the foreground). It seems like you would only need my
location while I am in the app.

You might get a higher acceptance rate.

------
lai
Did you use Google app engine for this and used a third party MongoDB
provider/own server? If it was GAE, what was it like using it? Was there
anything you didn't like?

------
aato
I'd be curious to know what kind of image recognition software the author used
to detect relevant images and if it came with a significant performance hit.

~~~
nathan_f77
I think you could do it very fast. It's just checking for the presence of
static elements in the image, and you don't even need to check for every
pixel. You would only need to decode the jpg and then check that maybe 30
pixels are the correct color (with a small tolerance). Also you know that
every image is coming from an iOS device, so you can throw out any images that
don't match a specific resolution, and you don't need to do any resizing or
anything. I'm surprised that he didn't talk about resizing images on the
device before uploading.

------
gwbas1c
Basically, the author knows that best practices are truisms and require common
sense to apply.

------
muneersn
Is there any way to simulate high load (Millions of users) for testing?

------
vacri
Aw... it's a $100/mo server, not a $100 server.

------
joesmo
His conclusion about Doctrine and other ORMs eating CPU and being the huge
bottleneck in the app lines up with my experience using the same. The MVC
framework itself, Symfony/Rails in his case, can indeed also be a huge bottle
neck, though much less than the ORM yet higher than the DB calls themselves.
That too has been my experience often.

