TL;DR style notes from articles I read today.
Choose boring technology
- Choose boring (read old and well used) technology for your tech stack because its capabilities, as well as its failures, are well understood.
- When choosing, you will have both known unknowns & unknown unknowns. Both sets are non-empty for all kinds of technology, boring or not. But the magnitude of unknown unknowns for new shiny technology is significantly larger.
- Remember that the “best” tool for the job is the one that will be on the “least worst” position for as many of your problems as possible.
- Mature developers understand that the long-term costs of keeping a system working reliably greatly exceed any inconveniences encountered while building it.
- In cases when new technology or tool that you must choose overlap or replace things already in use, ensure you migrate old functionality to the new system.
“Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.”
Full post here, 8 mins read
Goodbye microservices: from 100s of problem children to 1 superstar
Few takeaways from Segment’s journey of moving from a monolith to a microservice-style architecture & back to a monolith:
- A solution that looks like an instant & perfect fit in the current scenario may not be the best solution when you consider the potential scale of your system.
- While making technology decisions, we must also consider the long term operational costs & benefits of a solution.
- There are cons of a monolith: fault isolation is difficult, in-memory caching is less effective and updating the version of a dependency might break multiple other dependencies.
- But remember that adopting a popular trend can hurt both team productivity & product performance. Be fully prepared to deal with the costs of change when making a shift.
- Adopt a new trend only after getting a fair understanding of its implications on a scaled-up version of your current system.
Full post here, 13 mins read
Postgres is underrated - it handles more than you think
Lesser known but powerful features of Postgres:
- Postgres can cache too. Use shared_buffer config parameter in the Postgres config file to know how much memory it will use for caching data. Use pg_buffercache view to see what’s occupying the shared buffer cache of your instance. Use pg_prewarm function to load table data into either the OS cache or the Postgres buffer cache.
- Postgres can search quickly through text. It has a special data type tsvector, and a set of functions, like to_tsvector and to_tsquery to do this.
- Postgres provides a powerful server-side function environment in many programming languages. Pre-process as much data as you can on the Postgres server with server-side functions to cut down on the latency arising from passing too much data back & forth between your application servers and your database.
- Postgres has some powerful extensions. PostGIS is a specialized extension that can be used for geospatial data manipulation &running location queries in SQL. hstore extension allows storing and searching simple key-value pairs.
Full post here, 9 mins read
Top comments (0)