I am not sure I understand the pricing and/or the service. What are your guarantees about dropping or not dropping keys? Obviously you can't sell unlimited memcache space for 20$/mo and you must protect against customers exhausting all your available resources.
So since it's quite obvious that there must be some limit and/or expiration policy I think you should really just spell it out on the page.
We never drop keys unless the expire time is set. As long as someone isn't abusing the service by flooding it with random data, it will scale for them.
How do you determine if I am flooding your service with random data?
My understanding is that one of your main ideas is to encrypt the data so I am honestly wondering where you would even start to check if a user was randomly flooding you or legitimately storing lots of keys.
Not trying to pick nits here... My original point was that -- in my opinion -- it comes across slightly dishonest if you insist that there is no limit even when it's obvious there must be one. (I mean seriously, how many machines is this running on right now? Even if it's running on amazon/google you can only scale my backend up so much with 20$/mo)
Another kind of abuse could be to store huge chunk of data per key. Even with 10,000 keys if each key stores a 50 MB JSON blob you're storage cost could go up quickly.
It's an interesting idea, but I'm not sure there are very many potential use cases. Mostly, I can see using this client-side so that I don't need to set up a back end myself, but if I understand correctly, that's not really possible since you have to keep the API key private.
Yeah, I remember there was a service like this around 2009 (that, like this, I thought was pretty nifty... I wish I could remember the name) - but it was anonymous and you didn't need auth: you could write to a url and have the hash of it as the "read" endpoint... I used that for a lot of quick mock-ups and things.
I've used parse.com free account, created a class named 'cache' with columns 'key' & 'value'. The free plan's capacity is like 100k bigger than your highest paid plan. Sorry, I do not see the advantage of your service.
URLs have a tendency to end up in logs. Unless you are careful in your implementation (including what you inherit with your 'stack'), you may end up inadvertently persisting keys.
I like the idea of the pixel font, but find one that doesn't make the N look ugly. Silkscreen's usually a safe choice.
And I'd make the dev account more than 100 hits/day. I could easily go through that while actually coding, fixing bugs, repeat.
Since the use case is about quick, lightweight projects, I'd make creating an account optional until you need it. I'd want this to be as frictionless as possible, so that if I'm in the throes of coding and want the simplest possible key value store, I can just type in a URL like https://tinycache.io/api/myemail@address.com/CACHE_KEY and know it'll work without having to break out of my editor.
Thanks for the feedback.
In regards to the "font", that was actually done in photoshop. It's meant to look a bit pixelated and "off". But I'll probably tweak it to clean it up.
I'd really caution against your pricing structure. Unlimited access to a million keys is no joke, I've run some rather large memcached servers and none of them were $20/month.
You should pricing should always reflect the true cost + your desired profit margin. I'd probably be charging hardware usage + 15% before even factoring in the value of the service itself.
Right now I'd say you're vastly too cheap; don't think about the costs solely as your servers but what's the value you've added to memcached/caching? Surely that's more than what you're charging?
Tldr; Keep the small plans cheap but make the big plans waaay more expensive. Those using the biggest plans are finding the most value.
Thanks for the feedback, I will review the pricing to data storage cost.
My general thought is that most people won't max out the system, and that the cheaper accounts will offset the cost of the larger ones.
well, if you consider that they're probably just deploying on $5 and $10 digitalocean droplets, the 'unlimited' nature of the requests just means 'as much as your instance can handle', and there's a built-in profit margin.
Currently the service is in rackspace, and it's not cheap hosting. But yes, "unlimited" means as fast as the service can handle among all the other requests that are incoming too.
This service isn't designed to compete with something that has dedicated VMs and that kind of thing. It's vastly cheaper than most other data stores for this reason. Granted, it will scale for very heavy use. Right now, it's essentially launch day, so how much people use it will determine how I optimize it.
parse.com is essentially the same thing and it seems that it's popular enough. Of course it has a lot of polish and additional services on top of KV store but it's core value is key-value store with REST API.
Yes, similar idea. Mostly focused on personal applications, and small apps. Will probably add additional features in the future for doing more advanced queries, message queues, etc.
Hey everyone, all feedback is appreciated. The main point of the service is speed, and ease-of-implementation. It's very easy to setup an account, and the API is very simple.
Congratulations on releasing something out there. I think above all, you will walk away with some gained wisdom in various areas of web services that'll make your next project even better.
For personal use, this page explains how to setup a local script to work with the API. Makes it super easy to access whatever data you want across different computers.
My problem with a service like that is that once you jump out of the free plan, their prices jump way up. tinycache is a small service for small applications with small pricing.
Indeed. Although setting up a central data server with an API takes a bit more work. However, if you're willing to do the work and set all of that up yourself, than yes, the service isn't for you. I see it more as a simple way for someone to integrate their script or app without having to do a lot of the cloud-setup.
So since it's quite obvious that there must be some limit and/or expiration policy I think you should really just spell it out on the page.