architecture - I want to break my monolithic to microservices but I'm still stuck on it. Need advise -

so far, developing application planned available on web , mobile decided microservice.

what app can far listed below:

• sign (email, username, password, password_confirmation)
• sign in (email, password)
• sign in using facebook (automatically sign in if email exist in db, or create new record automatically sign in when email not exist in db)
• view articles
• post articles
• edit articles
• delete articles

as actions above, how many services should break into? i'm not sure split every actions in service sign-up-service / sign-in-service or group user-service right way.

an question, when split services separately how can articles data authors render on sites? build new broker service articles data within article-service author data within user-service after that? or, broker service no needed, articles data author data in web-application controller.

so far, developing application planned available on web , mobile decided microservice.

choosing microservice (ms) approach based on fact application support more 1 platform not advisable. if have never before dealt microservice architecture, perhaps better build modular monolith strong context boundaries. way easier focus on programming , implementing application, , later on can gradually break down monolith microservices, 1 @ time (i. e. start modules have low traffic, sign service). also, going straight microservices, except if doing project own experience or fun, suits category of premature optimization. more info monolith first approach, martin fowler wrote great article it.

as actions above, how many services should break into?

[i answering in context of splitting backend system , calling ms frontend via api.] sign , sign in should different service, sign used less (once user signs up, signs in on) sign in. facebook sign in go sign in ms. viewing articles more frequent posting, editing or deleting (either have blog platform or facebook), 1 ms provide data view articles, , 1 ms used post, edit or delete articles.

when split services separately how can articles data authors render on sites?

most adviced approach ms artchitecture polyglot persistence, every ms have own database, containing tables edits or updates. can take approach of accessing data of other ms through calling apis (view article service has, in article table, id of author, call user service/sign service id of author full info), though provides more tightly coupled architecture.

another option store data in form of events, new user registering event, gets stored in user service ms database , sent queue or topic, , other services can register receive events , store events in database. way duplicate data, have more loosely coupled (and asynchronous) architecture. google event driven data management more on approach.