I think a revisit of Conway's paper[1] might be appropriate. Between that, and the recent talk by Kevlin Henney about architecture[2], you'll be in far better shape to make such decisions.
Example of made up scenarios: You’re a singer. You recorded a song. How do you get people to listen to your song? You make up a scenario where your S.O. is just some random person and you play the song while doing something that shows attraction. Whether it’s hitting on the girl, or vice versa, or it’s puppies or something that invokes primal responses. Meanwhile the audio plays or you say “This is my song” and you have a dozen of your friends also promote it. Sit back and watch. A few people I know did this to break into the country music scene.
Guy in Truck: “Hey, you wanna hear something?”
Girl running: stops (pulls ear buds out like she couldn’t hear) “Sure” (confirming it was BS the whole time).
Music plays
Girl: “wow this is really good!”
Guy: “Thanks”, can I get your number?”
Girl: blushes and gives him a blank piece of paper because they are actually secretly married.
Lonely Planet travel guides are fantastic value. If you are going to spend >$500 to visit a foreign country/culture, spending $20 to learn the basics is cheap. And the practical knowledge can easily cover the cost of the book. I recently picked up one of these for a trip to Bosnia, and it offered a wealth of information about the country. The writer had a deep understanding of the country, the culture, the language and what you should know and what you should see. Even the restaurant recommendations were solid. If you are going to spend 8 hours traveling you ought have enough time to learn the basics of the place you are going to visit and lonely planet does a great job providing a high quality summary.
> As a rule of thumb, target utilization below 75%
This is one good reason to rely on serverless. Simply outsource the problem to a system that knows how to handle this better.
> Steer slower workloads to paths with lower utilization
This is fraught with all sorts of perils [0], so take caution going down this valid but tricky route.
> Limit variance as much as possible when utilization is high
This is key, and one of the most elegant solutions to this problem I know of comes from a Facebook talk on CoDel + Adaptive LIFO. [1]
> Implement backpressure in systems where it is not built-in
Making downstream dependencies behave is never an option. Selectively isolating noisy neighbours, if possible, from other well behaved clients, tends to work well for multi-tenant systems [2], in addition to monitoring long work (by dropping work that takes forever) [3], or better yet, doing constant amount of work [4] (aka eliminating modes) [5].
> Use throttling and load shedding to reduce pressure on downstream queues.
One way is to impl admission control (ala Token Bucket) to minimise the impact of thundering herds. Though, clients do not take kindly to being throttled. [6]
A great article; many have been written at this point. Very many still have been burned by queues. Though, in my experience, without an exception, some component somewhere was always building up that backlog! [7][8][9]
A pretty boring and stable year in SQLite land, which is just how I like it.
The JSON -> and ->> operators introduced in 3.38 are my personal favorites, as these really help in implementing my "ship early, then maybe iterate as you're starting to understand what you're doing" philosophy:
1. In the initial app.sqlite database, have a few tables, all with just a `TEXT` field containing serialized JSON, mapping 1:1 to in-app objects;
2. Once a semblance of a schema materializes, use -> and ->> to create `VIEW`s with actual field names and corresponding data types, and update in-app SELECT queries to use those. At this point, it's also safe to start communicating database details to other developers requiring read access to the app data;
3. As needed, convert those `VIEW`s to actual `TABLE`s, so INSERT/UPDATE queries can be converted as well, and developers-that-are-not-me can start updating app data.
The interesting part here is that step (3) is actually not required for, like, 60% of successful apps, and (of course) for 100% of failed apps, saving hundreds of hours of upfront schema/database development time. Basically, you get 'NoSQL/YOLO' benefits for initial development, while still being able to communicate actual database details once things get serious...
Worst case you’ve learned something new or had fun.
I am yet to regret a single instance when I regretted sharing unfinished, scrappy work:
https://untested.sonnet.io/Share+your+unfinished%2C+scrappy+...
One approach I really liked was the 2/2/2 rule:
2 hours for a poc → does this even make sense?
2 days for a prototype to share with friends
2 weeks to build something useful (paid if your goal is to charge for it)
You can leave the process at any stage. Each stage teaches you something new.