Real World Example

Amazon: "Every Team Talks Through APIs"

Around 2002 Amazon's leadership issued a famous rule: every team must expose its data and functionality through service interfaces, and teams must communicate only through those interfaces. No direct database reads, no shared memory, no back doors. This is exactly database per service + API contracts, and it later made it possible to sell those same services to the world as AWS.

Uber and Swiggy: Bounded Contexts in Practice

CompanyContextOwnsOthers get it via
UberTripstrip state, route, fare breakdownTrip API + "TripCompleted" events
UberPricingsurge multipliers, fare rulesQuote API
SwiggyRestaurantmenu, timings, open/closedRestaurant API, menu-change events
SwiggyDeliverypartner location, assignmentDelivery status events
NetflixPlaybacklicences, streaming URLsPlayback API

Note: Uber later grouped its ~2,000+ services into "domains" (Domain-Oriented Microservice Architecture) because too many tiny services became hard to manage. Right-sized services matter more than many services.

ShopEase: Configuration per Environment

application.yml

order-service reads the product-service URL from configuration, so the same code works on a laptop, in Docker Compose and in production:

order-service/src/main/resources/application.yml

shopease:
  services:
    product-url: ${PRODUCT_SERVICE_URL:http://localhost:8081}
    payment-url: ${PAYMENT_SERVICE_URL:http://localhost:8084}
spring:
  datasource:
    url: ${ORDER_DB_URL:jdbc:postgresql://localhost:5432/order_db}
    username: ${ORDER_DB_USER:order_svc}
    password: ${ORDER_DB_PASSWORD}

Example output

# laptop        -> http://localhost:8081
# docker compose -> PRODUCT_SERVICE_URL=http://product-service:8081
# kubernetes     -> PRODUCT_SERVICE_URL=http://product-service.shopease.svc:8081