The document discusses the architecture and design of a payment and shipping system built using Golang. It covers topics like code structure, dependency injection, microservices communication using gRPC, gRPC status codes, and some gRPC tricks. The system includes features like payment methods, address preferences, order requests, delivery tracking, and wallet/bank integration. It also discusses responsibilities of the payment system, potential issues to watch out for like import cycles and decoupling services, and concludes with recommendations on service design and performance.

1. What we learnt in using golang to
build payment and shipping system
Golang Gathering #31

3. - Overview of Payment and Shipping System
- How we are using golang and designing architecture
- Code structure
- Dependency injection
- Microservices communications
- gRPC status
- Some gRPC tricks
- Conclusion
Agenda

4. - There are features we covered
- Payment Method
- Address Preferences
- Create Listing
- Order Request
- Start Delivery
- Order Details
- Wallet and Bank
- Cashout
About Us - CarouPay

5. What system we gonna build

6. - Payment Processor
- 3+ payment partners
- work as interface towards all payment integrations
- Wallet
- user's purchases
- user's cash out
- user's balance
- Cashout
- transfer money to user’s bank account
- Ledger
- track every transaction that happens in the service
- track every status change for the above transactions
Responsibilities of Payment System

7. Code Structure
VS VS

8. Code Structure
VS VS
Do
Nothing
Service
Object
Based
Endpoint
Based

9. Something to be careful in structure design
Import
Cycle
Dependency
Injection
Decouple

10. Something to be careful in structure design
Import
Cycle
Dependency
Injection
Decouple

11. Import Cycle
- Put related things (e.g.
interface and struct)
together you can in a
package first.

12. Import Cycle
Company A
Company B
- Try to minimize the scope of package
as you can, like enum definition.
- And it’s also easily to be imported.

13. Something to be careful in structure design
Import
Cycle
Dependency
Injection
Decouple

14. - facebookgo/inject
- Package inject provides a reflect based injector.
- Object graph
- Singletons
Package Inject Facebook Injection

15. Facebook Injection Implementation
Declaration Implementation

16. Something to be careful in structure design
Import
Cycle
Dependency
Injection
Decouple

17. - Reporting package: Rollbar (rollbar/rollbar-go)
- gRPC Status
- All RPCs started at a client return a
`status` object composed of an integer
`code` and a string `message`.
- The gRPC client and server-side
implementations may also generate and
return `status` on their own when errors
happen.
- GRPC Status Code suits the need to
classifying the errors similar to HTTP
Status Code .
Error Reporting / Tracking
https://github.com/grpc/grpc/blob/master/doc/statuscodes.md

18. gRPC Status Implementation
Server Client

19. For example: an endpoint rough callstack of GetWallet
1. Endpoint (/wallet/) - decode / encode request and response
- Encode error response
2. Handler (FWHandler) - handle type conversion and construct response
- Return directly
3. Service (GetWallet) - handle key business logic
- Your error struct and determine which level of reporting
- cserror.New(http.StatusBadRequest, err, "description")
4. Object (Wallet) - like a wrapper and agent to communicate with database
- Common error (ErrorUserIDWrong, …)
5. Dao (UserWallet) - basic database query func
- Common error (ErrorEntryNotFound, ...)
Who should be the main guy to determine which type error

20. clients(web, mobile)
So...how do our microservices communicate?
|
API Gateway
OMS
LMS
Integration (7-11)
|
|
|
http
gRPC
gRPC
gRPC

21. - Grpc proto generation once you need to import other protos
- protoc --proto_path
- Properly use shell command sed to handle the content generated by protoc
- Determine which value of Oneof type object
- Use `paymentProvider.(type)` instead of `paymentProvider.(*proto.Stripe)`
- In most cases, you should use `Bytes` to represent string content rather than
define it as string
- Use protobuf built-in json marshaller (&jsonpb.Unmarshaler{})
- Context can include `metadata` to pass data like request header or user info
gRPC tricks

22. - API Gateway like a proxy only forwarding?
Or take some logics?
- Ideally only API gateway know each internal
services
- How to deal with heavy actions?
- Worker structure is still good
- How to make sure each action is really finished?
- TCC (Try cancel/confirm)-like pattern
- Should I select SQL or NoSQL database?
- In most of cases, Postgres is good and
cost-effective
- Is the number of microservices as repos?
- Not really
Something to be careful on designing microservices
clients(web, mobile)
|
API Gateway
OMS LMS
| |
http
gRPC|
PMS

23. - Most of endpoints only taken around 10 - 50 ms
- Easier to build up an API server that can handle QPS 5k+
- It’s important to have a style guide or a rule
- Be careful when splitting big component out as a service
Conclusion

24. Q&A

25. We are Hiring!

26. Senior Backend Developer (TW)
Junior/Senior Backend Developer (SG)
● Contact us for more information:
○ carol.lin@thecarousell.com
○ ronald.hsu@thecarousell.com
● Google `hothero 旋轉 面試`
We are Hiring!