Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The trick is to find "fault lines" throughout your monolith - places where it's easy to create separation of concerns and narrow interfaces. Maintain and document these like they are external APIs. Only pass simple data through it (serialized or anything easy to serialize).

When the time comes, cleave these chunks off and wrap them in RPC/REST/graphql.

It's good form even for monoliths since it makes for an easy interface to test.



+1 to you sir. I was just having a discussion this past weekend with some technical friends and noted that a well-architected monolith often lends itself to easy deconstruction such that you get the best of both worlds when they're necessary in your product lifecycle.


Good tip, and I learnt some new terminology too ("fault lines").

I guess the trick when building new monoliths is to identify these fault lines up front - as opposed to hopefully finding them later.

Will certainly guide my development going forward, thanks.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: