I want to start off by saying that having a monolithic application isn’t always a bad thing, and this article may not necessarily be for you. Yet. It just comes down to the correct timing of using microservices when it make sense and then diving into that work at the moment it’s needed, and not a moment later. Utilizing a microservices architecture too soon will hold you back and slow the development process back, whereas waiting too long to perform the migration makes the refactoring effort very painful.

  • If you have a single product that was designed well, is easily maintainable, and carries minimal technical debt, you may not have a lot of reasons to invest into a microservices architecture. Or certain areas are becoming areas of concern for performance and scalability, then you may slowly split those areas out.
  • If you’re like the rest of us dealing with multiple products through acquisitions, mergers, or reorganizations that were originally built in a time long ago before best practices existed for online services, there is little hope that it is maintainable or carrying minimal technical debt.

Continue reading

I got into a discussion this past week with one of my colleagues about rate limiting or throttling for APIs. In particular, how we might handle a user going beyond their limit and how we would inform them of what the threshold values are so they can continue calling later on. Neither of us came to an agreement – he took the 503 route and I took the 429 route.

As a side effect though, we took a look at some various companies out there, and found only a couple of HTTP response codes and headers, which all at least follow the same model, with only moderately different header names. For the most part, they all seemed to have these exact headers, or variations of them with slightly different names.Continue reading