6

As I see it, the size of the application doesn't really have much to do with the microservices pattern. After all, you can always choose to build a few large monoliths or to build a monolith out of lots of smaller libraries where it makes sense, or keep it in one large codebase using modules/namespaces/packages/whatever-your-language-offers. The use cases ...


1

Balance not saved in DB: When you are using event souring for your wallet service, then it is expected that you do not save the balance of the wallet in database. This is perfect. The balance should be computed by replaying all the transactions (events) Duplicate Transactions not processed: This sounds a bit risky to me. If duplicate transaction requests ...


1

Ok, So; I've managed to figure this out. I'll post the solution here for future reference. The Math: recordNumber = pageNumber x itemPerPage targetPageWithOffset = recordNumber / targetItemPerPage targetOffset = floor(targetPageWithOffset) targetPageOffset = targetOffset x targetItemPerPage for page 3 with 35 itemPerPage when source is 25 ItemPerPage (...


1

You will most likely want to buffer results from the external source, which might be advisable anyway when your service will be used by multiple users and you want to avoid scraping the source every time.


1

If possible, start simple (or spend more time analysing the actual usage patterns - eg read vs write). It might be that you can put a simple cache on the front to help with only read performance: a read pulls from the cache. If not cached, loaded from db into cache first a write writes through to db directly but also clears the cache entry This approach ...


1

Fixing the database should be a priority. Thoughts: Most data access follows the 80:20 rule. 80% of the requests use 20% of the data. And in that 20% the same applies. 80% of its accesses use only 20% of it's data. So caching can help. But now you have cache coherency issues. Does user A have a different cache from user B? Sometimes you don't care. ...


1

It's hard to tell from this context. As you present it, I'd be wary of introducing separate services at all. You can achieve loose coupling also within the context of one deployment unit. The services potentially can be classes. In my experience, microservices or modules with well defined and maintained API add an overhead. It's worth it only if it's ...


Only top voted, non community-wiki answers of a minimum length are eligible