START WITH SOMETHING YOU USE EVERY DAY
Imagine ordering food.
You search. Pick a restaurant. Add an item. Pay. Track the delivery. Get a notification.
You see one app.
Behind it, different parts of the product may have different jobs.
one customer experience
So what is a microservice?
responsible for a specific business capability — such as orders, payments or notifications.
The services communicate with each other through defined interfaces, often APIs or messaging systems.
One big application vs many smaller services
APPLICATION
Each service can have its own code, ownership and deployment.
But microservices don't remove complexity.
The complexity hasn't disappeared. Some of it has moved into the relationships between services.
Here's where the PM comes in.
“Add a new payment option.”
A seemingly small feature can cross several services and teams.
One failure can cross the system.
Now the delivery questions become important: retry? refund? reconcile? notify the customer? monitor the failure?
APIs become contracts between services.
“Is the API change compatible with the services that already depend on it?”
What you actually need to remember
THE PM LENS
Don't ask only: “Is the service done?”
That's the shift: understanding the architecture well enough to see ownership, dependencies, sequencing, risks and the conditions for the whole feature to work.
TECH WITHOUT THE JARGON · #02
Next time someone says “it's just a microservice change”...
you'll know there may be a whole network behind those few words.
Back to Writing →