Ride Sharing

Today I traced the full call flow of GetRoute — the function that sits at the core of trip previewing. Walking through each layer made the architecture concrete in a way that reading the files in isolation didn’t. Request Flow When a client wants to preview a trip, the request passes through three distinct layers before hitting the external routing API: Client POST /trip/preview {userID, pickup, destination} │ ▼ api-gateway/http.go : handleTripPreview - validates userID is present - re-serializes body as JSON - POST http://trip-service:8083/preview ──────────────────────┐ - wraps response in contracts.APIResponse{Data: ...} │ - returns 201 │ ▼ trip-service/infrastructure/http/http.go : HandleTripPreview - decodes previewTripRequest {userID, pickup, destination} - calls s.Service.GetRoute(ctx, pickup, destination) │ ▼ trip-service/service/service.go : GetRoute - builds OSRM URL with lon/lat coords - GET http://router.project-osrm.org/route/v1/driving/... - unmarshals JSON into OsrmApiResponse - returns routes {distance, duration, geometry{coordinates}} │ ▼ back to HandleTripPreview - writeJSON 200 with OsrmApiResponse Layer Responsibilities Each layer has a clear, single responsibility: ...

With the architecture designed in Day 1 and Go error patterns from Day 2, it’s time to build the first real service. The Trip Service is the heart of the platform — it owns the trip lifecycle. I started by scaffolding it using the generator tool: go run tools/create_service.go -name trip This gives us the Clean Architecture layout from Day 1: services/trip-service/ ├── cmd/ # Application entry point ├── internal/ │ ├── domain/ # Business domain models and interfaces │ │ └── trip.go │ ├── service/ # Business logic implementation │ │ └── service.go │ └── infrastructure/ # External dependency implementations │ ├── events/ # Event handling (RabbitMQ) │ ├── grpc/ # gRPC server handlers │ └── repository/ # Data persistence ├── pkg/ │ └── types/ # Shared types and models └── README.md Domain Layer The domain layer defines the core models and interfaces — no implementation details, no imports from infrastructure packages. ...

In Go, errors are values, not exceptions. There is no try/catch — instead, functions return an error as part of their return values, and the caller is responsible for checking it. This makes error handling explicit and forces you to think about failure paths at every step. The error Interface At its core, Go’s error type is just an interface: type error interface { Error() string } Any type that implements the Error() string method satisfies this interface. The built-in errors.New() and fmt.Errorf() are the most common ways to create errors. ...

After exploring the theory behind microservices in Day 0, it’s time to define what we’re actually building and why. What Are We Building? A ride-sharing platform — think Uber or Lyft. At its core, the problem is simple: a rider wants to go somewhere, and a driver can take them there. But the real complexity comes from making this work in real time. The key user flows are: Rider: pick a location on a map, preview the trip/fare, request a ride, get matched with a driver, and pay Driver: register with a car package, see incoming trip requests, accept or decline, and navigate to the rider What makes this interesting from a systems perspective is that nearly every interaction is time-sensitive and event-driven. When a rider requests a trip, we need to notify available drivers immediately. When a driver accepts, the rider needs to know right away. Polling or REST request-response alone won’t cut it. ...

References Strangler Fig Microservice Architecture pattern Service Micro Autonomous Loosely coupled Context bound Coupling — describes how much one module relies on other modules. Cohesion — how closely the responsibilities within a single module or component are related. Communication Styles Synchronous Request-Response (blocking) HTTP/REST (GraphQL or standard REST APIs) a ket concept in REST is a resource, which represents a business domain(User, Post, Trip) REST uses the HTTP verbs (GET, POST, PUT, DELETE) for manipulating resouces, which are referenced using a URL No strict contract; loosely defined via documentation text-based (JSON, XML) Excellent for public-facing APIs and scenerios where interoperabilty and ease of debugging are prioritized. ...