Application Architecture: A Quick Guide for Startups | Hacker News Reader

Application Architecture: A Quick Guide for Startups

cockroachlabs.com

31 pointsmakaimc16 comments

If you're architecting an early-stage startup, this article covers almost nothing of worth.

The two most important architectural factors for early-stage startups are:

1. product velocity; eg, the ability to move fast, experiment, and try things out in prod.

2. resource modeling; eg, what are the core data models that your product will use and how do they relate to each other?

Everything else is noise until you hit P/M fit.

#2 is less important than #1, but it's the really the only design point that can make or break ease of scalability post-P/M fit.

Yep! And to add to #1 I've seen people choose poorly and then write really bad code to make-up the velocity lost by the poor choice, and then see this as a virtue (eek!). A good choice should allow you to write fairly decent code, as it's natural to do so exactly because you chose a tech stack that fits the problem space! And if you're not quite sure what the problem space is, that means choosing a flexible tech stack and avoiding giant and costly assumptions.

Plus, they miss a key point of architecture: sustainability. You might take the 30’ somewhere and draw a high-level model like the ones depicted in the article, but who has time to continuously validate that devs actually follow the blueprint and make decisions should a need to change emerge? Nobody. And that’s OK. Architecture is not a magical ding an sich to be pursued but a way to organize things to achieve specific strategic goals. And for a startup, that goal is to survive until the liftoff. This survival very seldom involves investing heavily into architecture. Some experienced devs are going to be fine, neither the business nor the organization nor the system is going to be complex enough to merit dedicated attention to architecture. And if they are, something is wrong elsewhere (typically leadership)

> ding an sich

To be fair, while I never expected Kant to get involved in startup thinking, architecture as (not) a goal in itself is a very good point.

Could you elaborate a bit more on #2? What would be the implication of good/bad resource modeling.

Not GP, but an idiosyncratic data model that reflects a non-reality really encumbers momentum by introducing integration friction, arguments on the “right” way forward and generally causes a lot of noise. It can also make the team look like bozos when explaining the model to outsiders.

Isn't the operations behind Cockroach make velocity quicker? It takes care of alot of stuff for me. Have you tried the opensource version?

what's the general guide for #1? monolith app, schemaless database?

I think rather than optimise the application architecture optimise the tool chain, for rapid deployment, partial changes, blue/green deployments, etc. A hard separation between front and back ends is good too, so there can be a good UX but smoke and mirrors behind the scenes.

I don't know what startups you work at, but in the early stage I'm focused on keeping costs down as far as possible and producing features as fast as possible; not spending time architecting something I can do once I have a team and enough capital to develop it.

A single frontend, single backend, a single DBMS, a single data analysis tool which can connect directly. I don't need a warehouse when I have 5k users.

Hoe many startups did you see with multi region databases? Also, can you compare the approach to postgress + operators on kubernetes? And how do you charge for cockrouch db?

Their pricing: https://www.cockroachlabs.com/pricing/

You will inevitably rewrite everything right if you see good growth? This type of architecture stuff is surely over engineering mostly? Im not an engineer but have developed lots of web apps < 1000 users. Maybe outsource anything that requires this type of architecture, e.g. for satellite imagery processing GEE or Sentinel hub. Even then Sentinel Hub just serves from same region as where imagery presides. People are ok with that.

This seems excessive? Surely just a simple monolith into your chosen data storage is enough at the early stage until you start getting customers?

What other ways are companies accomplishing multi-region databases? It sounds like they claim their approach is better/different than Active-Active replication.

@Cockroach Labs - Please consider adding your service to Azure too :)

The many functionalities that make up an application are often organised according to a common pattern. The pattern of the application is specified by this pattern.

Reply on news.ycombinator.com