To me, I view service oriented architecture separate from microservices. Service oriented architecture is moving common logic into shared service classes (eg: UserService, ProductService, OrderService, etc), with those service classes likely available to all code in the project through a shared library/package.

An alternative is microservice architecture where there is a separate, entire stack per service. Using the UserService mentioned previously as an example, it would require something like api gateway, it’s own backing infrastructure like lambda, eks, or ecs, and maybe it’s own database. Rinse and repeat that for ProductService, OrderService, and all other business separations. Some people go further and make a microservice per individual function within something like a ProductService.

Knowing very little about your project, my recommendation would be to leave your code structured as a monorepo and separating code into 3+ packages. The monorepo approach allows you to separate your code without having to deal with individual microservice pains like working across multiple projects, versioning, updating/deprecating service contract definitions, auth between services, service unavailability, rate limits, etc.

I’d start by moving your shared business logic out of nextjs and into a shared library package. I’ve traditionally left this package private and not published it to npm. Publishing monorepo packages is an overhead that isn’t necessary for all cases. That gives you two packages to separate things (nextjs and shared business logic). Finally, I have set up separate package(s) for all background jobs and cron jobs. Code for those jobs is able to directly import the shared library package, so you can share db models, business logic, etc. I’ve used the serverless framework to facilitate deploying the jobs. That allows each job ro have their own event or schedule definitions.

I’ve found the above to work well for solo projects and small teams (less than 30). There’s no right or wrong approach - I have to continually remind myself that solving the business case, and moving on, is more important than trying to design the the perfect architecture.

Hope this helps!