Video summary
Golang Microservices Full Course #26 - Splitting Wallet Service
Main summary
Key takeaways
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
Walletservice 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.
Translate summary in another language
Ask questions to this video
Chat for follow-up questions, clarifications, and source-backed answers.