Full Stack Engineer — complete products, APIs & scalable architecture.

Why Clean Architecture

The system has many concerns that should not all live in the same place. Controllers receive HTTP requests, application services coordinate banking workflows, domain models represent banking concepts, and infrastructure handles database access, Identity, authentication, and external services. This keeps workflows like transfers, deposits, withdrawals, loan payments, and card payments easier to reason about because they are separated from HTTP and database configuration details.

Why Role-Based Access Control

A simple login system only confirms that a user exists. HermesBank needed to know what type of user is logged in and what that user is allowed to do. Admin users manage users, accounts, credit cards, loans, commerces, and administrative workflows. Clients handle transfers, beneficiaries, card transactions, and account views. ATM users handle deposits and withdrawals. Comercio users handle commerce payment workflows. JWT tokens include role claims for the API, and the MVC app uses cookie authentication with role-based authorization.

Why separate API and web application

The REST API exposes banking operations through versioned endpoints, making the backend useful for external clients, integrations, or future frontend applications. The MVC/Razor web app provides a complete user interface with role-specific views. Keeping these presentation surfaces separate makes the system more flexible while reusing the same application and infrastructure layers.

Why EF Core and repository pattern

Entity Framework Core with SQL Server handles persistence, while repositories keep database access separate from application workflows. Application services can focus on banking use cases such as creating accounts, processing payments, updating balances, assigning loans, and recording transactions without depending directly on DbContext details.

Why transaction records matter

In a banking system, changing a balance is not enough. HermesBank creates transaction records for transfers, deposits, withdrawals, and payments, including amount, transaction type, date, origin, beneficiary information, and status. This gives users and administrators traceability: where money came from, where it went, when it happened, and what operation was performed.

Why credit cards were included

Banking platforms usually involve more than savings accounts. HermesBank models credit card workflows such as assigning cards, updating limits, processing card transactions, tracking available credit, recording payments, and cancelling cards.

Why commerce payments were included

Commerce payments model a real payment-processing scenario. Commerce users can be linked to commerce records and process payments using card information, while administrators manage commerce records from a broader system perspective. This shows how role-based access can support more than admin and client workflows.

Why loans and amortization were included

Loans add long-running financial behavior. A loan is not a one-time operation; it has installments, payment status, interest, and scheduled updates. HermesBank includes loan assignment, loan payments, amortization schedules, installment tracking, and status updates.

Why Hangfire was used

Some banking workflows need background processing. Loan and amortization statuses may need updates even when no user is making a request. Hangfire runs recurring jobs for scheduled maintenance, including updates for overdue amortization installments and completed loans.

Why email notifications were added

Banking users expect to be informed when important financial activity happens. HermesBank sends emails for account and transaction-related events through an email service interface, keeping SMTP details separate from banking workflow logic.

Why Kafka over direct HTTP calls

When a student enrolls in a course, that one action needs to trigger a confirmation email, a push notification, analytics tracking, and a recommendation update. If every service had to respond immediately through HTTP, one slow service could make enrollment fail. With Kafka, enrollment completes first, then each service processes the event independently. If notifications are temporarily down, the student still gets enrolled and the notification is processed after recovery.

Why Docker Compose with health checks

Five services plus Kafka, Zookeeper, and Redis create startup-order problems. A service can appear to be running before it is actually ready. I configured health checks on critical dependencies so services only start when Kafka, Redis, databases, and related services are ready. This removed race-condition bugs during development and deployment.

Why separate database contexts

The core service uses separate EF Core contexts for business data and identity data. This keeps authentication infrastructure away from domain logic and lets each schema evolve independently without unnecessary risk.

Why .NET 10 for the core

The core service owns the most important workflows: payments, OAuth, JWT issuance, course management, and enrollment logic. .NET 10 was a strong fit because it performs well under load and handles async integrations with Stripe, Google, email, and Kafka cleanly.