Define architecture

[builder555]

Pick design strategy:

• plane
• microservies
• serverless
• custom-built backend
• something else?

Select data storage option

• SQL
• NoSQL
• something else?

[mcraa]

Do we have a budget cap? Or estimate how long we want to allow it to burn money before it starts earning? What are the revenue streams? (ads, financial consultancy, etc)

Should we define ^this before?

Questions for the arch:

• go for simplicity struggle later or
• future proof from the beginning (to some extent) burn a more struggle less

For the first, any monolith would suffice (springboot, asp mvc, ...) For the second path I would set up a kafka broker*, and let it swallow anything. Then we can build any service at any pace, getting data out of the message queue and putting it to any database and archive.

*that is google pub/sub since we want to start as many oob as possible

[mcraa]

explanation

• pub sub for high throughput, votes, comments, scraping can pour in at high frequency
• each service reads out the right data and persists to its own database (efficient data structure and db choice)
• service can publish back to pubsub or can be reachable by the end user and read out data from its own database

[mcraa]

arch.zip ^drawio xml for editing

[builder555]

Do we have a budget cap? Or estimate how long we want to allow it to burn money before it starts earning? What are the revenue streams? (ads, financial consultancy, etc)

I'm willing to put $500usd into this, if you want to throw in cash as well, then that's the limit. For revenue streams, I'd start with ads, and offer 2 subscription tiers: one for ad-free browsing and higher tier for ai-filtered content (explore this later)

Should we define ^this before?

Questions for the arch:

• go for simplicity struggle later or
• future proof from the beginning (to some extent) burn a more struggle less

simple is good, but need to put some thought into ability to expand later. since this is an experiment, i wouldn't want to spend 2 weeks designing a project that may be dead after 6 months.

For the first, any monolith would suffice (springboot, asp mvc, ...) For the second path I would set up a kafka broker*, and let it swallow anything. Then we can build any service at any pace, getting data out of the message queue and putting it to any database and archive.

*that is google pub/sub since we want to start as many oob as possible

[builder555]

explanation

• pub sub for high throughput, votes, comments, scraping can pour in at high frequency
• each service reads out the right data and persists to its own database (efficient data structure and db choice)
• service can publish back to pubsub or can be reachable by the end user and read out data from its own database

when a user visits the site, how do they get the stories? are they stored in edge servers' cache or fetched from services/DBs?

[mcraa]

explanation

• pub sub for high throughput, votes, comments, scraping can pour in at high frequency
• each service reads out the right data and persists to its own database (efficient data structure and db choice)
• service can publish back to pubsub or can be reachable by the end user and read out data from its own database

when a user visits the site, how do they get the stories? are they stored in edge servers' cache or fetched from services/DBs?

stories would come from the story db through the story service, catching is possible to add any time

[builder555]

stories would come from the story db through the story service, catching is possible to add any time

i guess we can add scaling later (if there's traffic spikes), to avoid the system freezing due to one service taking a long time