A Denial of Service attack, or DoS, is when someone from outside your system tries to overload it by sending a large number of requests, often targeting public APIs. The goal is to stop real users from being able to access your service. This is where rate limiting becomes important. If your endpoints are open and don’t have any limits, attackers can keep hitting them again and again. You can also use tools to block traffic from certain IPs or regions if you start to see suspicious activity.

The premise of zero bug policy is to redefine what is classified as a bug. Peter Hilton explains that the aim of the zero bug policy is to fix bugs before adding any new code. Switching gears frequently to fix bugs and test the new code can lead to unpredictable development timelines, which a zero bug policy can help to address. Within my company, bugs are called “live issues” and are immediately documented as user stories. This means that they get prioritised alongside all other user stories, so they carry the same value (in theory). So bugs are categorised as follows:  Bug found in production -> “Live issue” created as user story  Bug found during feature testing  Must be fixed before release -> User story, prioritised for development and testing  Feature will be released with bug present -> User story for that feature is updated to account for bug  Bug found during regression  Must be fixed -> User story created and added to backlog  Satisfied with existing workaround -> No new user story created  Bugs found during regression testing can point to a gap in testing: for example, tests were not updated when some requirements were changed. These, too, are categorised as user stories and can be prioritised accordingly.