TL;DR style notes from articles I read today.

Yes, you should estimate software projects

• It is obvious, but aim to deliver according to or ahead of your proposed timeline.
• Good communication is more important than perfect estimation. 
• If you see a delay coming, communicate well ahead and work with the business to decide whether it is worth cutting features, risk pulling in people off other projects, or push out the date.
• Be ready to discuss tradeoffs and prioritization if complexity is affecting the timeline. 
• Use missed estimates to build toolsets to deal with overlooked (or misunderstood) risks.
• Offer time-based measurements of tech debt to save time later.


Full post here, 8 mins read

The need for an API composition layer

• Heavily API-based platforms create significant technical overhead for developers.
• A separate API composition layer that squirrels away service integration to let developers focus on functionality is a potential solution.
• Let the API composition layer hold all the technical work of connecting every unique API and combine all the data sources for a project.
• Have the API composition platform automatically paginate and filter data, leaving the developer free to focus on the core application logic.
• Adopt a shared compositional logic.
• Using libraries & modules is the most lightweight option to adopt for API composition. Serverless is a close second. Microservices, if adopted with restraints, can work in some cases too. 


Full post here, 20 mins watch time

Three strategies for designing the caching in large-scale distributed system

• Always design the distributed systems to be ‘two mistakes high’ - handle failures at two levels so that there is at least one chance to recover instead of the system failing right away on a mistake.
• Place the web cache container in a side-car arrangement with each instance of your server/web service container. Any modification to the cache container does not affect the decoupled service.
• Place the cache above the service containers (or app replicas) so that all the containers can access the same cache replicas, and the cache can call the service in case of a miss.
• The above two approaches work for stateless services. If state is a significant factor for your app and there are many concurrent connections, sharded caching serves better.
• Use consistent hashing to distribute the load across multiple cache shards that show up as a single cache proxy to the user.

Full post here, 5 mins read

Get these notes directly to your inbox every weekday by signing up for my newsletter, in.snippets(), here.