Why to choose boring technology; monolith over microservices; & powers of Postgres
Tags: todayilearned, architecture, postgres
Published: 2019-10-30 11:44:30

*TL;DR style notes from articles I read today.*

### [Choose boring technology](http://bit.ly/2otc7fd)

- 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](http://bit.ly/2otc7fd), 8 mins read*

---

### [Goodbye microservices: from 100s of problem children to 1 superstar](http://bit.ly/2BX3Jbc )

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](http://bit.ly/2BX3Jbc ), 13 mins read*

---

### [Postgres is underrated - it handles more than you think](http://bit.ly/34iCTGB)

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](http://bit.ly/34iCTGB), 9 mins read*

---

*[Get these notes directly to your inbox every weekday by signing up for my newsletter, in.snippets(), here.](https://mailchi.mp/appsmith/insnippets?utm_source=devto&utm_medium=post08&utm_campaign=is)*