Is there any easy way to implement this pattern in AWS RDS deployments where we need to deploy multiple times a day and need it to be done in few minutes?
In my experience, this process typically spans multiple deploys. I would say the key insight that I have taken away from decades of applying this approach, is that data migrations need to be done in an __eventually consistent__ approach, rather than as an all-or-nothing, stop-the-world, global transaction or transformation.
Indeed, this pattern, in particular, is extremely useful in environments where you are trying to making changes to one part of a system while multiple deploys are happening across the entire system, or where you are dealing with a change that requires a large number of clients to be updated where you don't have direct control of those clients or they operate in a loosely-connected fashion.
So, regardless of AWS RDS as your underlying database technology, plan to break these steps up into individual deployment steps. I have, in fact, done this with systems deployed over AWS RDS, but also with systems deployed to on-prem SQL Server and Oracle, to nosql systems (this is especially helpful in those environments), to IoT and mobile systems, to data warehouse and analysis pipelines, and on and on.
Their docs show throughput limits (e.g., 4 CPU = 60 errors/sec), but what happens during error spikes?
If my app crashes and blasts hundreds of errors in seconds, does Telebugs have built-in rate limiting or backpressure? Or do I need to overprovision hardware/implement throttling myself?
With SaaS tools, spike protection is their problem. With self-hosted, I’m worried about overwhelming my own infrastructure without adding complexity.
Hey, Telebugs creator here. Great questions! Right now, Telebugs doesn’t have built-in throttling, so during error spikes, you’d either need to handle it manually or overprovision. I do plan to add throttling in the future, similar to what Sentry does, to protect your infrastructure automatically.
Curious: for those running self-hosted error trackers in production, how do you currently handle sudden error spikes? Any clever tricks or patterns you swear by?
The company I work for runs self hosted sentry. Sentry has something that tells you that events are being dropped due to pressure. I think every engineer in the company knows that this is happening but no one fixes it because no one has the time to look into it.
Thanks for your answer! Would you mind sharing your error volume? I’m also curious, how often do dropped events happen, and how does it impact your workflow? Any workarounds you’ve tried, or features you wish were available? This will help me make sure the feature is implemented in a way that’s actually useful.
I've used it a fair bit. My biggest use was for a computer processing system that recorded gigabytes of data. If it was limited to 60 inserts per second it would have taken months to run!
I do recall having to change some settings to make it really fast, but it wasn't 60/second slow.
Appreciate the answer! You’ve probably worked with raw SQLite drivers. I’m using a framework, which likely runs more transactions by default. I’m fairly confident that with a bit of digging, I can improve the ingestion speed. Good to know and thanks for sharing your experience!
> We can't really do much with the information that x amount is reserved for MCP, tool calling or the system prompt.
I actually think this is pretty useful information. It helps you evaluate whether an MCP server is worth the context cost. Similar for getting a feel for how much context certain tool uses use up. I feel like there's a way you can change the system prompt, and so that helps you evaluate if what you've got there is worth it also.
My theory is that you will never get this from a frontier model provider because as is alluded to in sibling thread the context window management is actually a good hunk of the secret sauce that makes these things effective and companies do not want to give that up
I’m experiencing something similar. We have a codebase of about 150k lines of backend code. On one hand, I feel significantly more productive - perhaps 400% more efficient when it comes to actually writing code. I can iterate on the same feature multiple times, refining it until it’s perfect.
However, the challenge has shifted to code review. I now spend the vast majority of my time reading code rather than writing it. You really need to build strong code-reading muscles. My process has become: read, scrap it, rewrite it, read again… and repeat until it’s done. This approach produces good results for me.
The issue is that not everyone has the same discipline to produce well-crafted code when using AI assistance. Many developers are satisfied once the code simply works. Since I review everything manually, I often discover issues that weren’t even mentioned. During reviews, I try to visualize the entire codebase and internalize everything to maintain a comprehensive understanding of the system’s scope.
I'm very surprised you find this workflow more efficient than just writing the code. I find constructing the mental model of the solution and how it fits into existing system and codebase to be 90% of effort, then actually writing the code is 10%. Admittedly, I don't have to write any boilerplate due to the problem domain and tech choices. Coding agents definitely help with the last 10% and also all the adjacent work - one-off scripts where I don't care about code quality.
I doubt it actually is. All the extra effort it takes to make the AI do something useful on non trivial tasks is going to end up being a wash in terms of productivity, if not a net negative. But it feels more productive because of how fast the AI can iterate.
And you get to pay some big corporation for the privilege.
> Many developers are satisfied once the code simply works.
In the general case, the only way to convince oneself that the code truly works is to reason through it, as testing only tests particular data points for particular properties. Hence, “simply works” is more like “appears to work for the cases I tried out”.
Yeah, MS Flight Simulator with a world that's "inspired by" ours... The original 2020 version had issues with things like the Sydney Harbour Bridge (did it have the Opera House?), using AI to generate 3D models of these things based on pictures would be crazy (of course they'd generate once, on 1st request).
So if you're the first to approach the Opera House, it would ask the engine for 3D models of the area, and it would query its image database, see the fancy opera house, and generate its own interpretation.. if there's no data (e.g. a landscape in the middle of Africa), it'd use the satellite image plus typical fauna of the region..
I believe there's games that have that already. My concern is that it's all going to be sameish slop. Read ten AI generated stories and you've read them all.
It could work, but they would have to both write unique prompts for each NPC (instead of "generate me 100 NPC personality prompts") and limit the possible interactions and behaviours.
But, emergent / generative behaviour would be interesting to a point. There's plenty of roguelikes / roguelites where this could work in, given their generative behaviours.
I guess for combat, you would want ones that could sensibly work together and adapt, possibly different levels of aggression, stealth etc Even as good as FEAR would be something.
Is there some clean way to pass components or just html to components using this framework without having them in strings? This is issue I see with most of these approaches.
Sadly this article just compares pricing. When we were using Google instead of HERE, results were mostly better but not worth the price. I would rather see some opinions on the quality of results and examples where each API shines and fails. Price without mentioning features and quality is incomplete information. People wont make decisions just based on the price.
