Microservices From Nasi Kerabu Perspective

We’re free to define things

Yesterday

I usually go to one my favourite warong to grab breakfast after my 5KM-jogging session during the weekend. Yesterday a guy behind me ordered Nasi Kerabu on behalf of another guy standing next to him without ulam (ginger buds, daun kesum, daun cekur, lemongrass, long beans, cabbage, bawang putih jeruk) & solok lada. I looked at him and jokingly said “tok genaplah boh sebab tok cukup kakah dio”. That guy laughed & replied “hom tulah saing ambo ni ore Ganu, pelik laa dio nii”. His friend waiting for the man who took their oder to handover the Nasi Kerabu, eagerly.

While driving back, that guy face & his version of Nasi Kerabu stucked in my mind. That man defined his own version of Nasi Kerabu by choosing the ingredients he want. Those combination, for him, still a menu deserve to be called as Nasi Kerabu. Why I became sensitive with the way that guy constructed/built his Nasi Kerabu? Was that because I’ve been living in a world where Nasi Kerabu must be defined in certain specific way?

Prequel

Last week I jammed into a session with my Engineering Lead to discuss about one of our products that went through revamp process for scalability purposes. He briefed me about Laravel Queue that he placed in the flow together with RabbitMQ. There are microservices configured behind the message broker — ready to process incoming traffic independently and concurrently.

Producer, message broker and consumer are typical layers that define inter-system communication in order to achieve microservices oriented architecture. Message broker is one of the go-to stacks to decouple a large monolithic system. I knew that. What challenged me / new to me was — the Laravel Queue.

Microservices architecture is a lego-style design practise. The pieces people used to build stuff might be different but the fundamental is the same. I think same goes to Nasi Kerabu. You can opt-in kuah tumis, mix with budu or eat with ikan celup tepung instead of grilled meat.