IOE Pulchowk Campus, Microservices

This session at IOE Pulchowk Campus covered microservices: an architecture in which an application is built as a set of small services, each owning its own data and deployable on its own, rather than as a single unit that ships all at once.

The material starts where the difficulty actually is, which is the boundaries. Services drawn around business capabilities — ordering, billing, inventory — can change independently; services drawn around technical layers cannot, and produce a distributed system that still has to be released in lockstep. From there the session covers how services talk to each other, synchronously over HTTP or gRPC and asynchronously through a message broker, and why the asynchronous path is what decouples a caller from a callee's availability. Data is the other half: once each service owns its own store there is no distributed transaction to fall back on, so consistency has to be reached over time, through events and compensating actions rather than a single commit.

The session is deliberate about the cost, because microservices are usually taught as an upgrade. Splitting a system multiplies everything operational around it — deployment, service discovery, configuration, and above all observability, since a request that used to be one stack trace becomes a path across several processes that has to be traced to be understood. A monolith with clean internal boundaries is the better answer far more often than the architecture's popularity suggests, and knowing which problem justifies the split is the part that is hard to pick up on the job.

Pulchowk students are among the most technically prepared in the country, so the fundamentals are rarely what is missing. What is useful is the failure modes: the ways a distributed system breaks that a single deployable one cannot, and the decisions that become expensive to reverse once services are running in production.