These days we all are told to build stateless applications. Stateless apps are those that don’t store any state in the application process and fetch any state from a centralised datastore (it could be a global cache or a database). The sixth factor in 12 factor app also talk about the same principle.
Execute the app as one or more stateless processes
Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.
There are advantages in building stateless applications primary being ability to scale horizontally with ease. When we build stateless applications we push the scalability problem to the database. We expect our database to scale horizontally. This usually is solved by sticking a global cache (Redis or Memcached) in between. Scaling cache is relatively easy and solved problem. Keeping cache updated with updates is a hard problem. We will discuss it some other time.
Continue reading “4 Reasons You Might Want To Build Stateful Apps”
I have worked with multiple software development teams that because of feature delivery pressure does not apply best practices. This later leads to tech debt and cost more time. In the last project team that I helped they made two small mistakes:
- They didn’t use pagination in the collection resources. They were fetching the list of data from the database and returning back to the user as JSON. During development when data was small they didn’t face any issues. But, later when customer started doing testing it became a monumental task to add pagination in all the collection resources.
- They were returning domain entities in the response. This meant they were transferring more data over the wire than it was necessary.
So, they were breaking two best practices:
- Using pagination for collection resources
- Keep your domain object different from representation object
Continue reading “Using ArchUnit To Enforce Architecture Best Practices”
I love the idea of everything as code. It enables use of version control for all aspects of software development. These days we use everything as code approach for documentation, infrastructure provisioning, deployment automation, continuous integration build jobs, pull request and issue templates, and many other things. The beauty of this approach is that it enables us to use the same tools as we use use for software development.
One aspect of the software development where we are lacking the as code approach is in creating architecture diagrams.
Continue reading “Software Architecture Diagrams as Code”
All software has software architecture. This is true even when a team has not spent time coming up with it. This architecture is often called Big ball of Mud. A big ball of mud architecture is a software system that lacks a perceivable architecture.
Every software system has a software architecture is similar to saying not taking a decision is also a decision.
Continue reading “Architecture Hoisting”
Today, I read a paper titled Lessons from Giant-Scale Services. This paper is written by Eric Brewer, the guy behind CAP theorem. It is an old paper published in 2001. The paper helps the reader build mental model on how to think about availability of large scale distributed systems.
Continue reading “Paper Summary: Lessons from Giant-Scale Services”