Video summary

Golang Microservices Full Course #26 - Splitting Wallet Service

Main summary

Key takeaways

Technology

Summary

The episode extracts wallet functionality from the monolith into a dedicated Wallet Service, alongside the existing API gateway, authentication service, and user service. The wallet database and table are moved out of the user service so wallet data is owned by the new service.

Wallet Service design and implementation

  • Adds a separate wallet database, initialization SQL, migration files, Dockerfile, and Go service entry point.
  • Defines a gRPC Wallet service with operations to create a wallet, retrieve a wallet by user ID, and update a wallet balance.
  • Uses a signed amount for balance updates: positive amounts add funds, while negative amounts deduct funds. Requests also include an expected version for optimistic locking.
  • Returns the wallet ID, user ID, balance, and version. Currency is omitted because the tutorial supports only one currency.
  • Adds repository and handler layers for database access. Balance updates use transactions and checks intended to prevent invalid balances.

Integration with the user service

The user service calls the Wallet Service over gRPC to provision a wallet during registration. Wallet repository logic and the wallets table are removed from the user service, which now uses a wallet gRPC client instead.

Docker Compose is updated to start the Wallet Service and provide its gRPC address to the services that need it.

Debugging and testing

Registration initially failed because the Wallet Service could not be reached. The tutorial explains the distinction between the address a client uses to dial a service and the address a server uses to listen. The service should listen on its own container interface and port, while clients use the configured service address.

After correcting the setup, the presenter verifies that the services start, separate databases exist, and registration creates both a user and a wallet with an initial balance and version.

Email verification

The presenter also adds an email-verification link endpoint and updates the login flow to reject users whose email is unverified. Verification status is included in the user service’s protobuf response. A test confirms that clicking the emailed link changes the user’s status and that only verified users can log in.

Guide and source

This is a hands-on implementation guide covering service extraction, gRPC integration, database migrations, Docker Compose configuration, debugging, and an email-verification update. It does not present a product review.

Main speaker/source: The video’s presenter, Ikhda Muhammad Wildani, who also consults an AI assistant while debugging the connection issue.

Rate this summary

Your feedback will help improve summaries.

Improve this summary

Reprocess with a stronger model when the summary feels incomplete or inaccurate.

Pro

Translate summary in another language

Pro

Ask questions to this video

Chat for follow-up questions, clarifications, and source-backed answers.

Coming soon

Share this summary

Original video