IIIT Bangalore Students: Using a Java Internship to Explore Microservices Without Overreaching

Yes, a two-week Java internship is enough to explore microservices, as long as “explore” means one clean split of a small monolith into two services with a written API contract, not a full migration. The safest approach is to score the split against a rubric first, build only the seam that survives that scoring, and treat “keep it a modular monolith” as a legitimate finding.

This guide gives you a 14-day scope, a contract template, a scoring rubric for deciding when microservices are not worth the complexity, and a worked illustrative example. It also covers how this kind of exercise fits alongside the final-semester internship rules at IIIT Bangalore.

Why a 14-day Java internship punishes ambitious microservice plans

Microservices add costs that a monolith does not have: network calls that can fail, separate deployments, duplicated configuration, data that no longer lives in one transaction, and debugging across process boundaries. In a fourteen-day window you pay these costs up front and rarely reach the payoff, which is independent scaling and independent team ownership.

The common overreaching patterns look like this:

• Splitting into five or six services because the domain “has” five or six nouns.
• Adding a message broker, a service registry, an API gateway and a tracing stack before two services can talk to each other reliably.
• Sharing one database between the services, which keeps the coupling but adds the network.
• Skipping the written contract and letting the two services agree only through whatever the code happens to do.
• Judging success by the number of services instead of by whether each one can change without breaking the other.

A better target is small and checkable: two services, one contract, one data owner per service, one end-to-end flow that works, and a short written verdict on whether the split was worth it.

Scoring rubric: when microservices are not worth the extra complexity

Run this rubric before writing any new code. Score each row 0, 1 or 2 based on your actual project, not on how the architecture would look in a portfolio. Higher means a stronger case for splitting.

Reading your score for a 14-day scope

• 0-6: Do not split. Refactor into packages or modules with a clear interface inside one deployable. Document the seam so that a later split is cheap.
• 7-11: Build a modular monolith with the contract written as if it were a service. If time remains, run the module as a second process purely as a learning exercise, and label it that way in your write-up.
• 12-18: A two-service split is defensible. Keep it to exactly two services.

Two rows act as veto signals regardless of total. If data separability or transaction coupling scores 0, stop and fix the model first, because splitting across tightly coupled data produces a distributed monolith.

Choosing the seam in a small monolith

A good first seam has three properties: it does one thing nameable in a sentence, its data can be described without joining to the rest of the schema, and the rest of the application needs only a few of its operations.

Seam-finding steps

1. List modules by package. In a typical Spring Boot project this means the controller, service and repository clusters for each business area.
2. Draw the dependency arrows. Note which package calls which. A candidate with arrows pointing only inward (others call it, it calls nobody) is the easiest to extract.
3. Trace the data. For each candidate, list the tables it reads and writes. Any table touched by both sides is a problem to resolve before extraction.
4. Count the operations. If the rest of the app needs more than about five distinct operations from the candidate, the boundary is probably in the wrong place.
5. Pick the side-effect-heavy part. Notifications, report generation, file processing and audit logging usually have the cleanest seams because their callers do not need an immediate answer.

A 14-day plan that stays inside two services

If you are working through the free two-week online internship from CareerSwami, use the same fourteen days and pick the Java track project that fits this scope. Offer letter and completion certificate come with successful completion, but they are separate from your architecture write-up, which is the artefact that shows your thinking.

Writing the API contract before the code

The contract is the main deliverable. It is what lets two services change independently, so write it before extracting anything and keep it short. Cover these elements for every operation:

• Path, method and purpose in one sentence.
• Request fields with types, which are required, and validation limits.
• Response fields and status codes, including every error you intend to return.
• Idempotency: what happens if the caller sends the same request twice.
• Timeout expectation and what the caller should do on failure.
• Versioning rule, such as a /v1 path prefix, and what counts as a breaking change.
• Ownership: which service owns which identifier and who may create it.

An illustrative contract fragment in OpenAPI style (not executed or validated, shown only to illustrate structure):

paths:
  /v1/notifications:
    post:
      summary: Queue a notification for a registered user
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [requestId, userId, templateCode]
              properties:
                requestId:    { type: string, description: "Caller-generated; repeat = same result" }
                userId:       { type: string }
                templateCode: { type: string, enum: [REGISTRATION_CONFIRMED, EVENT_REMINDER] }
      responses:
        "202": { description: Accepted for delivery }
        "400": { description: Unknown template or missing field }
        "409": { description: requestId already processed }

Note the requestId. It makes the call safe to retry, which matters once a network sits between the two services.

Worked illustration: splitting notifications from a campus event registration app

This example is illustrative, with invented numbers, and no code or tests were run for it.

Imagine a Spring Boot monolith for campus event registration with four areas: Events, Registrations, Users and Notifications. One student built it alone. Notifications sends confirmation emails and reminders, and currently does so inside the registration transaction.

The total is 11, which falls in the modular-monolith band. The honest verdict: the real benefit is failure isolation, not scale or team autonomy. The student therefore extracts Notifications as a learning exercise, labels it as such, and records that for a one-person project with this load, the modular monolith alone would be the production choice. The exercise still produces a contract, a retry rule and a failure test, which is exactly the evidence an interviewer can discuss.

Handling data, failures and testing across the split

Data

• Give each service its own schema or database. Cross-service references are IDs, never foreign keys across the boundary.
• If the notification service needs a user’s email, either pass it in the request or fetch it through a documented endpoint. Do not read the other service’s tables.

Failures

• Set an explicit connection and read timeout on the HTTP client.
• Decide what the caller does when the call fails: queue and retry later, drop with a log entry, or surface an error. Write that decision in the contract.
• Test the failure by stopping the second service and recording what the user sees.

Tests

• A consumer-side test that checks the client sends a request matching the contract.
• A provider-side test that checks the service returns documented status codes.
• One integration test through both processes. Keep it small so that it runs in seconds.

IIIT Bangalore students: placing a short microservices exercise next to your final-semester internship rules

IIIT Bangalore’s formal internship expectations are much larger than a fourteen-day project. The recruiter guidelines for 2026-27 graduates say final-semester students (mid-December to mid-June) complete 16-20 credits through one of four modes: a full-time industry internship, a faculty-supervised thesis, a research project or exchange programme, or a startup under the IIIT-B Innovation Center. The same document treats the internship as equivalent to a thesis in an industry setting, requiring a clear problem description, at least one mid-term report and a final completion certificate in the prescribed format.

The placements overview page adds that at least 5.5 months of the chosen option must be completed by 15 June and that a report and certificate are due by 20 June. This page sits under a test-style path, so check the live version before relying on the dates.

In practice, a two-week exercise is preparation, not a substitute. It will not meet a months-long duration or a prescribed-format certificate. Where it helps is in building a concrete architecture story and a decision record that you can discuss with a prospective host company when internship offers are being made. The placements overview page lists internship-related recruitment months, including September-October for 6-month internships, so a finished write-up is useful before then.

The guidelines also say the problem description must be clear. The scoping habit in this article (one seam, one contract, one verdict) is the same discipline, applied to your own project.

Verification steps for IIIT-B students

1. Ask the Placement Office (iiitb_placement@iiitb.ac.in, the address the guidelines give for recruiters) or your programme office whether any short online internship can count toward anything. Do not assume it earns credit.
2. Request the current academic regulations for your batch and read the internship and thesis sections for credit and evaluation weightage.
3. Confirm the live dates for the mid-term report and the final submission against the current academic calendar.
4. Ask your faculty advisor whether an architecture write-up like this one is useful for the final-semester problem description.
5. If you plan to mention this exercise to a recruiter, check with your placement representative how the one-job-per-student policy and offer timelines apply to your batch.

The decision record: what to hand in at the end of day 14

A one-page decision record is more convincing than an extra service. Include these headings:

• Context: what the monolith does and its size.
• Rubric result: the table and the band it fell into.
• Decision: what you built and what you chose not to build.
• Contract summary: operations, error codes and versioning rule.
• Failure behaviour: what happens when the second service is down.
• Measured differences: startup time, number of moving parts, lines of configuration, as you actually observed them.
• Would I ship this? A direct answer with reasons, which can be “no”.

Scope cuts that keep the exercise honest

• Skip Kubernetes. Docker Compose, or two plain processes, is enough.
• Skip a service mesh, a gateway and a registry. Hard-code the base URL in configuration.
• Skip a message broker unless the rubric specifically calls for asynchronous delivery; a synchronous call with a timeout teaches the same contract lessons.
• Skip authentication between services unless your project needs it, and note that gap in the decision record.
• Skip a third service. Adding one multiplies integration work without adding new ideas.

Frequently Asked Questions

Can I really learn microservices in 14 days?

You can learn the boundary skills: choosing a seam, writing a contract, handling a failed call and testing across processes. You will not learn operating microservices at scale, which needs sustained production exposure.

Should my project end with two services even if the rubric says not to split?

If the score lands in the lower band, build the modular monolith and write the contract against the in-process interface. If you still extract a second process, label it a learning exercise in your README. Presenting it as the right production design would be misleading.

Is a shared database ever acceptable between two services?

It defeats the main benefit, since a schema change in one service can break the other. For a short exercise it is better to give each service its own schema and pass IDs, even if both schemas sit on one database server.

REST or messaging for the first split?

Use REST with an explicit timeout for the first split because it is easiest to test and debug. Consider messaging only when the rubric shows that the caller must not wait, and keep it to one queue.

Will this internship count for credit at IIIT Bangalore?

The CareerSwami internship is free and gives an offer letter and a completion certificate on successful completion. It is not described as academic credit. The institute’s own credit rules for final-semester options are separate, so ask your programme office about them.

What should I put on my resume from this exercise?

Describe what you actually did: “split a Java monolith into two services with a versioned API contract and contract tests, and documented a rubric-based decision.” Do not claim production usage, scale figures or tools you did not use.

How do I know the monolith is small enough?

If you can describe every package and its tables from memory in five minutes, it is the right size. A few entities and a handful of endpoints are enough to demonstrate the seam.

What if my contract needs to change midway?

Change the contract file first, update both sides and the contract tests, and note the change in the decision record. Practising this loop is part of the learning. If a change is breaking, bump the version path instead of silently altering behaviour.

Related Java & Enterprise Software guides

• Geetanjali University Students: A LinkedIn Update Plan for Your Java Internship
• JSS Science & Technology University: Writing Clean Java Code a Mentor Will Approve
• Al-Karim University Students: Starting a Java Internship With Only Basic English Confidence
• All Java & Enterprise Software internship guides